perm filename CLCLEA.MSG[COM,LSP]7 blob
sn#850576 filedate 1987-12-21 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00018 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00004 00002
C00005 00003 ∂28-Nov-87 0534 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00011 00004 ∂28-Nov-87 1105 CL-Cleanup-mailer Issue status
C00016 00005 ∂30-Nov-87 0921 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00019 00006 ∂30-Nov-87 1446 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00029 00007 ∂30-Nov-87 1733 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00031 00008 ∂30-Nov-87 1911 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00032 00009 ∂01-Dec-87 0025 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00034 00010 ∂01-Dec-87 0038 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
C00037 00011 ∂01-Dec-87 0100 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00040 00012 ∂01-Dec-87 0923 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00043 00013 ∂01-Dec-87 1042 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00045 00014 ∂01-Dec-87 1043 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00047 00015 ∂01-Dec-87 1102 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00058 00016 ∂01-Dec-87 1103 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
C00064 00017 ∂01-Dec-87 1201 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
C00068 00018 ∂01-Dec-87 1756 CL-Cleanup-mailer CL-CLEANUP membership
C00072 ENDMK
C⊗;
∂28-Nov-87 0534 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 87 05:34:09 PST
Received: by labrea.stanford.edu; Sat, 28 Nov 87 05:32:29 PST
Received: from bhopal.lucid.com by edsel id AA28590g; Sat, 28 Nov 87 05:26:50 PST
Received: by bhopal id AA17747g; Sat, 28 Nov 87 05:27:53 PST
Date: Sat, 28 Nov 87 05:27:53 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8711281327.AA17747@bhopal.lucid.com>
To: labrea!Dave.Touretzky%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: Dave.Touretzky@C.CS.CMU.EDU's message of Mon 16 Nov 87 01:57:08-EST <12350990498.13.TOURETZKY@C.CS.CMU.EDU>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
There's one sense in which I share Fahlman's reluctance to accept this idea.
It seems to presume that underlying any array whatsoever is a simple
vector of elements that represent the array in dense, row-major order.
In fact, Lucid Common Lisp does just about that (as all the others do too,
I suspect!). There is even an "internal" function named
'underlying-simple-vector'
to fetch that simple vector.
But the problem is that the simple-vector needn't be "dense" in elements
of the array! The existence of the function array-row-major-index doesn't
require, for example, that there be no gaps between the rows. [The
definition on CLtL, p293 is only one possibility -- the one for dense
underlying simple-vectors.] Rather, it only requires a 1-1 mapping
between the integers {0,1,...(1- <array-total-size>)} and the full set of
multi-dimensional indices.
Your characterization of the relation between arrays and sequences exhibits
the bias towards dense, underlying simple vectors:
Let me restate the basic intuition one more time. A sequence is like
a string of beads. If you stretch it out straight you have a list or
vector. If you fold it up in various ways using COERCE or MAP, you
have an n-dimensional array which you can access with AREF, which is
not a sequence function. The beads still sit on the string in the same
order, and the sequence functions still give the same result no matter
how you fold the string of beads. This property is guaranteed by the
existing commitment in CLtL to storing array elements in row-major order.
"Ordering" may be guaranteed by row-major order; but "density" isn't.
Not even the existence of :displaced-index-offset guarantees "density"
(especially if it's value is typically row-aligned anyway), although
I admit that you won't get portable results if you can't assume density.
Until it is decided that a particular implementation of multi-dimensional
arrays is *standard* (as opposed to the functional interface to multi-
dimensional arrays), then Common Lisp implementations should be free
to store the rows of a matrix in any random way that is convenient to
the storage layout of that implementation (e.g., "sparse" storage?).
I must confess that on "stock" hardware, it would be rather inefficient not
to use the dense, row-major odering. But closing off other implementation
options seems premature, to me; at least until there is evidence of a *great*
win to be had by doing so.
-- JonL --
∂28-Nov-87 1105 CL-Cleanup-mailer Issue status
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 87 11:05:33 PST
Received: by labrea.stanford.edu; Sat, 28 Nov 87 11:03:53 PST
Received: from kent-state.lucid.com by edsel id AA29214g; Sat, 28 Nov 87 10:57:29 PST
Received: by kent-state id AA05304g; Sat, 28 Nov 87 10:58:08 PST
Date: Sat, 28 Nov 87 10:58:08 PST
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8711281858.AA05304@kent-state.lucid.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 25 Nov 87 17:49 PST <871125-174935-2663@Xerox>
Subject: Issue status
Date: 25 Nov 87 17:49 PST
From: Masinter.pa@Xerox.COM
This isn't quite up to date as I've missed a few, but I thought I should
go ahead and send it out if you're keeping a score card... I think we
have some new members of the distribution list as of the last week or
so...
- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)
Ready for release
Perhaps you missed my message about this issue, since I sent it during
the meeting. Here it is again:
There's a problem with this SETF method for symbols. Consider the
following simplified version of SETF from p.107 of CLtL:
(DEFMACRO SETF (REFERENCE VALUE)
(MULTIPLE-VALUE-BIND (VARS VALS STORES STORE-FORM ACCESS-FORM)
(GET-SETF-METHOD REFERENCE)
(DECLARE (IGNORE ACCESS-FORM))
`(LET* ,(MAPCAR #'LIST (APPEND VARS STORES) (APPEND VALS (LIST VALUE)))
,STORE-FORM)))
This results in the following macrexpansion for (SETF X 1), using the
new SETF method for symbols:
(LET* ((G0002 X)
(G0001 1))
(SETQ X G0001))
The value of G0002 is never used. The problem is that X might be
unbound, so even just binding it to a local variable will fail. I
don't think we want to require implementations to eliminate
unnecessary bindings in SETF expansions, just to get correct
semantics. Nor should each SETF-like macro need a special case when
the location being stored is a symbol.
Unfortunately, I think special handling for symbols is necessary. If
we keep the SETF method for symbols the way it is in CLtL then we need
to make a special case for symbols in the SETF methods for GETF, LDB
and the like. If we change the SETF method as proposed here, we need
to make a special case for symbols in SETF and PSETF and any user
defined SETF-like macro that doesn't use the fifth value (ACCESS-FORM)
from GET-SETF-METHOD.
My feeling is that we should go with the new SETF method for symbols,
but describe this problem and point out to implementors that SETF and
PSETF must handle symbols specially, effectively resorting to the old
SETF method.
∂30-Nov-87 0921 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87 09:21:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 290628; Mon 30-Nov-87 12:19:35 EST
Date: Mon, 30 Nov 87 12:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: Dave.Touretzky@C.CS.CMU.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8711281327.AA17747@bhopal.lucid.com>
Message-ID: <19871130171930.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 28 Nov 87 05:27:53 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
There's one sense in which I share Fahlman's reluctance to accept this idea.
It seems to presume that underlying any array whatsoever is a simple
vector of elements that represent the array in dense, row-major order.
....
That was clearly the intention of Common Lisp, although I note that the
only place in CLtL that says this explicitly is an example on p.289.
It can also be deduced from the definitions of array-total-size and
array-row-major-index, because the range of array-row-major-index's
answer is defined to be a range of integers that contains just enough
members to supply a value for each subscript set, with no gaps.
Since CLtL was not explicit enough to be clear to you, perhaps a cleanup
proposal in the "clarification" category is needed.
∂30-Nov-87 1446 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 87 14:46:37 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 30 Nov 87 17:46:03 EST
Received: by kali.think.com; Mon, 30 Nov 87 17:45:59 EST
Date: Mon, 30 Nov 87 17:45:59 EST
From: gls@Think.COM
Message-Id: <8711302245.AA00685@kali.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 20 Nov 87 12:34 PST <871120-123444-1850@Xerox>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
Issue: FORMAT-COLON-UPARROW-SCOPE
References: CLtL p. 406 and also p. 403
Category: CLARIFICATION
Edit history: version 1: Guy Steele, 30 November 1987
Problem description:
Implementations currently differ on the question of what is tested by the
FORMAT command "~:↑". Some implementations test to see whether any
arguments remain in the sublist for the current iteration step; others test
to see whether any sublists remain. The text on page 406 is not clear
on this point.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if the sublist
that is supplying the arguments for the current iteration step is the
last sublist (in the case of ~:{) or the last FORMAT argument (~:@{).
Note that ~:↑ is *not* equivalent to ~:#↑; the latter terminates the
entire iteration if and only if no arguments remain for the current
iteration step.
Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if no more arguments
remain for the current iteration step. Thus ~:↑ is equivalent to ~:#↑,
just as ~↑ is equivalent to ~#↑.
Test Cases/Examples:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
this yields "a...b".
Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
this yields "a".
Rationale:
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS is desirable
because otherwise there is no way to test whether any sublists remain.
The text on page 406 may be construed to hint at this proposal
indirectly. To quote Nick Gall:
If one thinks about the intent of the parenthetical
(because in the standard case it tests for remaining arguments of
the current step only)
one should agree that "a...b" will be returned. In referring to ~↑ as
the "standard case", which tests the arguments remaining in the
current argument sublist, this parenthetical implies that there is
an `other case', which tests `something else.' The only `other case'
discussed is ~:↑, which therefore must test `something else.' I claim
that the parentheical makes no sense if we interpret ~:↑ as testing
the same condition as ~↑. If they both test the same condition, why
have the parenthetical explanation?
If ~:↑ doesn't test the same condition as ~↑, then what does it test?
I claim that the only test that makes sense is for ~:↑ to test the
only thing that affects the "entire iteration process:" the number of
sublists. When there are no more sublists, "the entire iteration
process" is terminated.
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS is desirable
only because it maintains the equivalence of ~:#↑ and ~:↑ and because
some implementations have been produced that take this approach.
Current practice:
Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
include Symbolics Common Lisp.
Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, and VAXLISP.
Cost to Implementors:
One or the other batch of implementors will have to make a one-line change.
Cost to Users:
It is unlikely that much user code depends on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS, but it is
possible. The author of this writeup (Steele) judges it somewhat more
likely that user code might depend on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Cost of non-adoption:
Users would have to be warned not to use ~:↑ in code that is meant to be
portable.
Benefits:
Elimination of yet one more ambiguity.
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS allows greater
semantic power (there are more things one can test).
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS maintains an
elegant but useless symmetry.
Esthetics:
Absolutely none. We're talking about FORMAT here.
Discussion:
Nick Gall favors FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Kevin Layer, Rich Robbins, and Robert Poor have spoken in favor of
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS.
Guy Steele strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
Historical note: Steele first implemented this "feature", in Zetalisp, and
so the code in Symbolics Common Lisp is likely a direct descendant of the
original code. This might cause some to give weight to Steele's opinion.
There are two arguments against such credence. First, there is no reason
why the original code should be regarded as part of the specification of
Common Lisp any more than any other implementation; plainly, Steele botched
the specification when he wrote the book. Second, a professor of
literature (I believe) once told Isaac Asimov concerning a short story of
his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the
story, what makes you think you know what it means?"
∂30-Nov-87 1733 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87 17:33:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291206; Mon 30-Nov-87 20:33:04 EST
Date: Mon, 30 Nov 87 20:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: gls@Think.COM
In-Reply-To: <8711302245.AA00685@kali.think.com>
Message-ID: <19871201013304.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks ready for release to me, unless we don't want to release any
discussions containing more than one proposal. In that case, my vote is
with FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS on the grounds
of its greater expressive power and slightly lower cost to users.
∂30-Nov-87 1911 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 87 19:11:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 15:50:53 PST
Date: Mon, 30 Nov 87 15:50:47 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
In-reply-to: <8711302245.AA00685@kali.think.com>
To: cl-cleanup@sail.stanford.edu
Message-ID: <871130-155053-1317@Xerox>
I also favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.
∂01-Dec-87 0025 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87 00:25:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 15:29:31 PST
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871130-152931-1269@Xerox>
Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming"
, says:
"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin
(DEFUN + (&REST NUMBERS) ...)
Its type is
(FUNCTION (&REST NUMBER) NUMBER)."
Unfortunately, I've never found the place in CLtL where such a recommendation is
made.
∂01-Dec-87 0038 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 00:37:55 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291526; Tue 1-Dec-87 11:26:00 EST
Date: Tue, 1 Dec 87 11:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
To: gls@Think.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8711302245.AA00685@kali.think.com>
Message-ID: <871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I side with TEST-FOR-REMAINING-SUBLISTS because it offers important
flexibility that is otherwise tricky to obtain.
If we can reach consensus within the group, I'd like to see the proposal
rewritten to contain only one proposal.
If we have to retain two proposals, I think the TEST-FOR-REMAINING-ARGUMENTS
is going to need its rationale/benefits beefed up a bit. As it stands,
Steele argues only elegance and then goes on to say later that
aesthetics doesn't count in FORMAT. I don't think this is going to win
many people who are hanging in the balance.
I think the remark about aesthetics not counting at all in FORMAT is cute
but not strictly true. But since I don't have anything more consequential
to write there, I'll suggest the following compromise presentation which
(for the sake of casual readers and future historians) makes it more clear
that we're being flippant -- or at least less clear that we're being
serious...
Aesthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele, Jr.
∂01-Dec-87 0100 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 01:00:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291565; Tue 1-Dec-87 11:46:33 EST
Date: Tue, 1 Dec 87 11:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871130-152931-1269@Xerox>
Message-ID: <19871201164614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming", says:
"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin
(DEFUN + (&REST NUMBERS) ...)
Its type is
(FUNCTION (&REST NUMBER) NUMBER)."
Unfortunately, I've never found the place in CLtL where such a recommendation is
made.
That's because there isn't one. Note that the reference was to "Steele", not
to CLtL. It can be found in document X3J13 / 86-003, a many-times photocopied
5 page document that is apparently entitled "A:>GLS>clarifications.text.4".
A scribble on my copy says "be explicit about &optional, colons; remanded
to declarations committee." I suppose the declarations committee is one of
those vapor committees that never produces anything? This seems like a
reasonable thing for the Cleanup committee to address, expanded to cover
all lambda-list keywords in FUNCTION type-specifiers, not just &REST.
∂01-Dec-87 0923 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 01:00:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291565; Tue 1-Dec-87 11:46:33 EST
Date: Tue, 1 Dec 87 11:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871130-152931-1269@Xerox>
Message-ID: <19871201164614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming", says:
"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin
(DEFUN + (&REST NUMBERS) ...)
Its type is
(FUNCTION (&REST NUMBER) NUMBER)."
Unfortunately, I've never found the place in CLtL where such a recommendation is
made.
That's because there isn't one. Note that the reference was to "Steele", not
to CLtL. It can be found in document X3J13 / 86-003, a many-times photocopied
5 page document that is apparently entitled "A:>GLS>clarifications.text.4".
A scribble on my copy says "be explicit about &optional, colons; remanded
to declarations committee." I suppose the declarations committee is one of
those vapor committees that never produces anything? This seems like a
reasonable thing for the Cleanup committee to address, expanded to cover
all lambda-list keywords in FUNCTION type-specifiers, not just &REST.
∂01-Dec-87 1042 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 10:42:13 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01261; Tue, 1 Dec 87 13:44:29 EST
Message-Id: <8712011844.AA01261@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
In-Reply-To: Your message of Tue, 01 Dec 87 11:25:00 -0500.
<871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 13:44:24 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>
Despite my earlier comments on the common-lisp mailing list, I also
now favor TEST-FOR-REMAINING-ARGUMENTS. It does gain more power.
∂01-Dec-87 1043 CL-Cleanup-mailer Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 10:43:35 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01311; Tue, 1 Dec 87 13:45:51 EST
Message-Id: <8712011845.AA01311@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
In-Reply-To: Your message of Tue, 01 Dec 87 11:25:00 -0500.
<871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 13:45:41 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>
Ooops, make that TEST-FOR-REMIANING-SUBLISTS. Braino.
∂01-Dec-87 1102 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 11:02:44 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12488; Tue, 1 Dec 87 12:02:15 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA15709; Tue, 1 Dec 87 12:02:09 MST
Date: Tue, 1 Dec 87 12:02:09 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712011902.AA15709@orion.utah.edu>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: cl-cleanup@sail.stanford.edu
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p.47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-KEY-NAME
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Test Case:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Many Common Lisp
implementations currently ignore FUNCTION type declarations.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the type of the &REST parameter
must be LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Ugly. Since the argument type syntax used by the FUNCTION type specifier
mirrors normal lambda-list syntax, it is confusing to make the &REST type
to refer to the types of the actual arguments rather than the type of the
matching lambda variable.
Discussion:
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:EXTEND-LIST-TYPE):
(1) Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST refers to the type of the corresponding lambda variable and must
be LIST or a subtype of LIST.
(2) Introduce a list form of the LIST type specifier, (LIST <type>), to
specify a list where the value of each successive CAR of the list is a
member of type <type>.
(3) Introduce a list form of the SEQUENCE type specifier, (SEQUENCE <type>),
to specify a sequence where the value of each successive element is a
member of type <type>.
Test Case:
The type of the function + would be specified as:
(FUNCTION (&REST (LIST NUMBER)) NUMBER)
Rationale:
(1) It is clear that a &REST lambda variable must be bound to a list.
Since the FUNCTION type syntax follows lambda-list syntax rather than
function call syntax, it is more consistent to make the type correspond to
the type of the lambda variable rather than that of the actual arguments.
(2) Introducing a list LIST type specifier would allow the FUNCTION type
specifier to be more useful for its intended purpose. It would also be
useful on its own. For example, a compiler may be able to optimize
calls to functions such as MAPCAR that operate on successive elements of
a list if information is available about the type of items in the list.
The motivation for making this part of the standard is that the syntax
of the LIST type cannot cannot be extended by user code.
(3) This is an obvious extension of (2).
Current practice:
There does not appear to be any concensus on this issue. Many Common Lisp
implementations currently ignore FUNCTION type declarations.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to
do so. It should be a fairly straightforward to implement the list
forms of the LIST and SEQUENCE type specifiers.
Cost to Users:
Users who have been using the convention that the &REST type parameter
specifies the type of the actual arguments will have to change their code.
However, because this issue is so unclear, the FUNCTION type specifier is
probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Since the argument type syntax used by the FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide
the type of the lambda variable rather than the type of the actual arguments.
Discussion:
-------
∂01-Dec-87 1103 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 11:03:14 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12513; Tue, 1 Dec 87 12:02:44 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA15714; Tue, 1 Dec 87 12:02:36 MST
Date: Tue, 1 Dec 87 12:02:36 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712011902.AA15714@orion.utah.edu>
Subject: Issue: FUNCTION-TYPE-KEY-NAME
To: cl-cleanup@sail.stanford.edu
Issue: FUNCTION-TYPE-KEY-NAME
References: CLtL p.47-48, 61
Category: CLARIFICATION, CHANGE
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, there is a problem with &KEY
lambda variables because keyword arguments may be specified in arbitrary
order in both the the lambda list and the actual argument list. It is not
possible to match up the types specified in the FUNCTION declaration to
either actual arguments or lambda variables without additional information.
Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):
(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda
list should be supplied as lists of the form (<keyword> <type>). The
<keyword> must be a symbol in the keyword package.
(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda
list.
Test Case:
The type of the function SORT could be specified as:
(FUNCTION (SEQUENCE FUNCTION &KEY (:KEY FUNCTION)) SEQUENCE)
Rationale:
(1) This specifies a direct correspondence between the argument type and
its matching keyword. All of the information is in one place, and the user
does not have to remember (or even know) the order in which &KEY arguments
appear in the actual function definition.
(2) This is probably an oversight in the original specification.
Current practice:
Many Common Lisp implementations currently ignore FUNCTION type
declarations. The situation regarding type specifications for keyword
arguments is so ambiguous that few users attempt to use them.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier or keyword arguments
in a FUNCTION type specifier may continue to do so. This proposal should
not involve massive amounts of code to be rewritten.
Conversion Cost:
Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations check for, and warn about, old-style usage.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.
Discussion:
-------
∂01-Dec-87 1201 CL-Cleanup-mailer Issue: FUNCTION-TYPE-KEY-NAME
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 12:01:16 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291874; Tue 1-Dec-87 15:00:39 EST
Date: Tue, 1 Dec 87 15:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-KEY-NAME
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8712011902.AA15714@orion.utah.edu>
Message-ID: <871201150013.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I am generally sympathetic to the SPECIFY-KEYWORD proposal but can't really
endorse it in its current form because...
* The problem description should make it clear that the problem is not
the keywords can be in any order in the formal and actual argument
lists, but rather just that CLtL is not clear on how the matchup is
specified. It is "possible", it's just not "defined".
* Item one of the proposal should not require that the <keyword> be in
the keyword package since there is a proposal on the floor to loosen
this requirement for keywords. Instead it should state that the <keyword>
must be a valid keyword-name symbol.
* Should we make it explicit that SUPPLIED-P information is either allowed
or disallowed in FUNCTION declarations? (I see no reason to allow it but
maybe I'm overlooking something.)
* The test case is wrong because the word SORT is omitted in the declaration.
This is presumably just a typo.
Also, though, it looks funny because of the :KEY and because the type
FUNCTION is also probably the user's idea of the argument's name. These
"coincidences" don't make the example wrong but make it hard to focus on
the points it's trying to make.
I suggest picking another example. MAKE-LIST comes to mind. eg:
(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)
∂01-Dec-87 1756 CL-Cleanup-mailer CL-CLEANUP membership
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87 17:54:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 11:40:08 PST
Date: 30 Nov 87 11:39 PST
From: Masinter.pa@Xerox.COM
Subject: CL-CLEANUP membership
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871130-114008-117@Xerox>
There are a number of people who are either observers or members of this
subcommittee and were not listed in Mathis' announcement.
> Date: 29 Nov 87 17:22 EST
> Subject: subcommittees
> From: MATHIS@A.ISI.EDU
> To: x3j13@SAIL.STANFORD.EDU
> Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>
> here is my version of how the subcommittee evolved at the Ft. Collins
> meeting. PLEASE send me any additions or other corrections.
> If you have an electronic mailing list, please let me know and tell
> me how people outside the subcommittee should be involved with that
> list (if at all)
> X3J13 Subcommittees (as of November 29, 1987
> (Mathis, Steele, and Gabriel try to follow all)
> Clean-up
> Larry Masinter
> Guy Steele
> Kent Pitman
> JonL White
> JScott Fahlman
> David Moon
> Ellen Waldrum
Rather than my embarassing myself by misspelling your name or otherwise mangling
the introduction, or including some and not others... Lets have another round
of mail-check: For those who are not in the list above, please send a brief
message to CL-CLEANUP@SU-AI.STANFORD.EDU, introducing yourself. Please do not
use the word "Axolotl" in your reply.
- - - - -
This is the current distribution list for cl-cleanup@Sail.stanford.edu:
rpg
#clclea.msg[com,lsp]
Fahlman@C.CS.CMU.EDU
chiles@C.CS.CMU.EDU
ram@C.CS.CMU.EDU
mcdonald@C.CS.CMU.EDU
gls@THINK.COM
"xerox-cl-cleanup↑.pa"@XEROX.COM
(Brotsky.PA, Daniels.PA, Gregor.PA, Masinter.PA, Pavel.PA, Pedersen.PA)
(redistribution to: "Dieter Kolb:ZTISOF:Siemens")
"hpfclp!dcm"@HPLABS.HP.COM
"hpfclp!cl-technical"@HPLABS.HP.COM
kmp@SCRC-STONY-BROOK.ARPA
Moon@SCRC-STONY-BROOK.ARPA
"edsel!cl-cleanup-dist"@LABREA.STANFORD.EDU
Mathis@C.ISI.EDU
brittain@A.ISI.EDU
mly-lispm@AI.AI.MIT.EDU
JAR-CL@AI.AI.MIT.EDU
"willc%tekchips.tek.com"@RELAY.CS.NET
"Haug%ti-csl"@RELAY.CS.NET
"Waldrum%ti-csl"@RELAY.CS.NET
wjr@SCRC-STONY-BROOK.ARPA
"chapman%aitg.dec"@DECWRL.DEC.COM
pierson@multimax.arpa
"franz!akbar!layer"@ucbarpa.Berkeley.EDU
padget@RAND-UNIX.ARPA
∂01-Dec-87 2016 CL-Cleanup-mailer introduction
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87 20:16:29 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA02402; Tue, 1 Dec 87 20:16:38 PST
Received: from akbar by franz (5.5/3.14)
id AA09817; Tue, 1 Dec 87 20:07:56 PST
Received: by akbar (5.5/3.14)
id AA28657; Tue, 1 Dec 87 20:03:54 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)
Return-Path: <akbar!layer>
Message-Id: <8712020403.AA28657@akbar>
To: cl-cleanup@sail.stanford.edu
Subject: introduction
Date: Tue, 01 Dec 87 20:03:53 PST
Hello,
I'm a lisp hacker a Franz Inc. and I'm mainly on the cleanup mailing
list to monitor the activity and pitch in the "current practice" for
our Common Lisp (Allegro CL, used to be Extended Common Lisp). I
also volunteered to write-up a few issues at the Ft. Collins meeting,
which I'll be getting to soon...
Kevin Layer
ucbvax!franz!layer
layer%franz.uucp@Berkeley.EDU
∂01-Dec-87 2053 CL-Cleanup-mailer introduction
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87 20:53:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 292457; Tue 1-Dec-87 23:22:58 EST
Date: Tue, 1 Dec 87 23:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: introduction
To: Kevin Layer <franz!akbar!layer@ucbarpa.Berkeley.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712020403.AA28657@akbar>
Message-ID: <19871202042310.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 20:03:53 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)
I'm a lisp hacker a Franz Inc. and I'm mainly on the cleanup mailing
list to monitor the activity and pitch in the "current practice" for
our Common Lisp (Allegro CL, used to be Extended Common Lisp).
Welcome. I think we've suffered from a lack of coverage in the
"current practice" department, so I'm glad to see you join.
∂02-Dec-87 1008 CL-Cleanup-mailer Re: CL-CLEANUP membership
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 10:08:43 PST
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 2 Dec 87 10:03:14-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 2 Dec 87 10:08:24 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 2 Dec 87 10:27:53 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 2 Dec 87 10:27:35 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 2 Dec 87 10:26:14 mst
Return-Path: <dcm@hpfcdcm>
To: cl-cleanup@sail.stanford.edu
Subject: Re: CL-CLEANUP membership
X-Mailer: mh6.5
In-Reply-To: Your message of 30 Nov 87 11:39:00 -0800.
<871130-114008-117@Xerox>
Date: Wed, 02 Dec 87 10:26:05 MST
Message-Id: <13622.565464365@hpfcdcm>
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
"hpfclp!dcm"@HPLABS.HP.COM
Dave Matthews of Hewlett Packard. I am following the
conversation and provide current practice information when
appropriate.
"hpfclp!cl-technical"@HPLABS.HP.COM
Pipe to notes system for other reviewers within HP.
Dave
∂02-Dec-87 1119 CL-Cleanup-mailer Re: CL-CLEANUP membership
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 87 11:19:09 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA00566; Wed, 2 Dec 87 14:23:06 EST
Message-Id: <8712021923.AA00566@multimax.ARPA>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
Subject: Re: CL-CLEANUP membership
In-Reply-To: Your message of 30 Nov 87 11:39:00 -0800.
<871130-114008-117@Xerox>
Date: Wed, 02 Dec 87 14:23:02 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
I'm Dan Pierson <pierson@multimax.arpa> working on Common Lisp for the
Encore Multimax. First serial, then parallel (the Multimax is a
shared memory multiprocessor). I'm currently working on four writeups
for this committee.
∂02-Dec-87 1202 CL-Cleanup-mailer intro
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 12:02:17 PST
Date: Wed, 2 Dec 87 15:05:57 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: intro
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <293701.871202.JAR@AI.AI.MIT.EDU>
I'm Jonathan Rees (JAR@AI.AI.MIT.EDU). I'm a graduate student at MIT
working on Scheme and related things, and also a consultant for the VAX
(Common) Lisp development group at DEC.
∂02-Dec-87 1421 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 14:20:51 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 2 Dec 87 17:20:07 EST
Received: by kali.think.com; Wed, 2 Dec 87 17:20:03 EST
Date: Wed, 2 Dec 87 17:20:03 EST
From: gls@Think.COM
Message-Id: <8712022220.AA04837@kali.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Nov 87 12:25 PST <871123-122535-2508@Xerox>
Subject: Issue: APPEND-DOTTED (Version 4)
I support APPEND-DOTTED:REPLACE, version 4.
∂02-Dec-87 1422 CL-Cleanup-mailer Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 14:22:09 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 2 Dec 87 17:20:55 EST
Received: by kali.think.com; Wed, 2 Dec 87 17:20:50 EST
Date: Wed, 2 Dec 87 17:20:50 EST
From: gls@Think.COM
Message-Id: <8712022220.AA04840@kali.think.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Nov 87 12:42 PST <871123-124211-2551@Xerox>
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)
I am indifferent on this issue.
∂02-Dec-87 1528 CL-Cleanup-mailer intro
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 15:28:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 87 14:47:16 PST
Date: Wed, 2 Dec 87 14:31:47 PST
From: Pavel.pa@Xerox.COM
Subject: intro
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871202-144716-1018@Xerox>
I'm Pavel Curtis (Pavel.pa@Xerox.Com) and I'm currently trying both to finish my
thesis and not to get overly committed to work on any proposals unless there's a
crying need. I read all of the ones that come across, though. I expect to be
much more active when the thesis is done, in another couple of months or so.
Pavel
∂02-Dec-87 1941 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87 19:41:22 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Dec 87 22:40:45-EST
Date: Wed, 2 Dec 1987 22:40 EST
Message-ID: <FAHLMAN.12355411187.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
In-reply-to: Msg of 1 Dec 1987 11:46-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Rather than introduce some godawful kludge for declaring the type of
&rest lists (only), we should probably try to clean up the inadequacies
of the LIST data-type specification. There should be some long-form
declaration for LIST that allows you to declare the element-type and
length, similar to the declarations for vectors.
We might or might not want to add a "true list" data type at the same
time. A "true list" is finite in the CDR direction and terminates in
NIL. I can forsee some arguments about whether LIST in a declaration
should mean "true list", or whetehr we should give a new name to true
lists.
This is just a trial balloon -- if there is some enthusiasm for this
idea, I'll turn it into a real proposal. If not, we can go back to
discussing kludges for indicating the element-type in an &REST list.
-- Scott
∂02-Dec-87 2043 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 20:42:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 20:41:08 PST
Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Wed, 2 Dec
87 22:40 EST
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-204108-1072@Xerox>
I'm tempted to try to address several issues with FUNCTION declarations at once.
1) I realize now that I do not understand the import of *any* of the argument
type specifiers, and specificly the language about "at least of the types
specified" that appears in CLtL p 47. However, I don't know what
(declare (function my-cons (float string) list) )
means. It says that my-cons is a function that can "accept a floating-point
number and a string (among other things), and its result is an object of type
list...."
The problem is that the argument type declaration here is of absolutely no use.
That the declared function can accept a float and a string among other things
has no content. It doesn't say that it is illegal to pass a non-float as the
first argument. It says that if you pass a float, its ok, and if you pass a
non-float, it might be OK too. Isn't that the same as saying (function my-cons
(t t) list)?
It would be more valuable as far as I can see to say that a (function (float
string) list) is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?
2) On the specific issue at hand: I'm inclined to be more sympathetic to
allowing &REST <element-type>; function type specifiers are, after all, already
a specialized little language -- the &KEY arguments have a separate syntax which
only vaguely resembles the original lambda list syntax, for example.
3) Should the function type specifier also allow &ALLOW-OTHER-KEYS?
Here is some (old) mail from the Common Lisp mailing list which touches on some
related issues:
!
Date: 18 Apr 1986 16:07-EST
Subject: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
Question: What is the 'most informative' type specifier for the CL function
COPY-SEQ?
How 'bout? (function (sequence) sequence)
Unfortunately, this does not tell the reader nor the compiler that if the
argument is a list, then the result is also a list, and vice versa. So how
about this:
(or (function (list) list)
(function (vector) vector))
This is syntactically valid CL, and the definition of the OR and FUNCTION type
specifiers makes it meaningful. Unfortunately, it is not clear from pg. 158
whether or not the following is legal:
(proclaim '(ftype (or (function (list) list)
(function (vector) vector))
copy-seq))
It is not legal in VaxLisp, and my guess is that there aren't any
implementations that would do the right thing with it. So I would like to
propose that such a use of OR/FUNCTION be considered legal CL.
Without such a declaration, one is forced to either wrap (the <result-type> ...)
around all calls to such functions or to DECLARE a restricted version of
FUNCTION in the appropriate places, e.g., (defun foo (alist avector)
(declare (list alist)
(vector avector)
(function copy-seq (list) list))
(zap (copy-seq alist)
(let ()
(declare (function copy-seq (vector) vector))
(zoop (copy-seq avector))))
Either method is a real pain.
This use of OR would give CL something akin to Ada overloading. It allows the
overloading of multiple 'function type signatures' on a single function name.
Such overloading is already implicit throughout CL (esp. the seq. functions).
My proposal would merely allow a way of describing it.
-- Nick
!
Date: Mon, 4 Nov 85 22:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Declaring Functions
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
In-Reply-To: <8511012045.AA07112@utah-orion.ARPA>
Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same?
Read page 159 more carefully. It explains that they have the same meaning, but
are syntactically different. "function" has the disadvantage that you can only
declare one thing per clause, unlike most other declarations, but the advantage
that it looks mildly like "defun".
If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.
If by keywords you mean &optional and friends, it isn't strictly necessary to
repeat that, although it would sure clear things up if there were a cross
reference in the book.
However, there appears to be a typo on page 159. The form following the phrase
"entirely equivalent to", which currently reads
(ftype (function arglist result-type1 result-type2 ...) name)
ought to read
(ftype (function arglist (values result-type1 result-type2 ...)) name)
in order to be consistent with page 47.
∂02-Dec-87 2146 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 21:46:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 21:42:53 PST
Date: Wed, 2 Dec 87 21:42:47 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: <871202-204108-1072@Xerox>
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-214253-1099@Xerox>
Larry says:
``I don't know what (declare (function my-cons (float string) list) ) means.''
It is usual in type theory for this to be read as an implication:
IF
you pass a float and a string to MY-CONS
THEN
MY-CONS is guaranteed to return a list.
More rigorously, a type theorist would see (function my-cons (float string)
list) as representing the set of all functions that, when applied to a float and
a string, return a list.
Under this view of types, we understand the constructor OR to be set-union (that
is, the type (OR t1 t2) represents the set of values in the union of the sets
represented by t1 and t2) and the AND constructor is thus set intersection.
Under this view, Nick Gall gives the wrong answer to his question about a
specific type for COPY-SEQ when he claims that a good one would be
(or (function (list) list)
(function (vector) vector))
Since this does not guarantee that COPY-SEQ will return a list when applied to a
list; in fact, a function in this type might very well bomb when presented with
a list. In general, ORing function types isn't very helpful. What he really
wants here is AND, not OR:
(and (function (list) list)
(function (vector) vector))
This represents the set of functions that both map lists to lists and vectors to
vectors.
Let me point out that I'm not claiming that this is how CLtL intends function
types to be interpreted, just that this meaning has proven very convenient for
most uses.
Pavel
∂02-Dec-87 2225 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 22:25:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 22:20:29 PST
Date: 2 Dec 87 22:20 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Pavel.pa's message of Wed, 2 Dec 87 21:42:47 PST
To: Pavel.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-222029-1111@Xerox>
Under the interpretation outlined in your message, it would not be valid to assume, given
(declare (function my-cons (float string) list) )
that
(typep (my-cons x y) 'list)
can be assumed, unless it was also asserted (declare (float x) (string y))?
∂02-Dec-87 2236 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87 22:36:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 22:36:23 PST
Date: Wed, 2 Dec 87 22:36:17 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: <871202-222029-1111@Xerox>
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-223623-1122@Xerox>
That's right. Unless you know something about the types of the arguments, you
can assume nothing about the type of the result.
Pavel
∂03-Dec-87 0953 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 87 09:53:41 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 294082; Thu 3-Dec-87 12:53:18 EST
Date: Thu, 3 Dec 87 12:52 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
In-Reply-To: <871202-204108-1072@Xerox>
Message-ID: <871203125256.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM
...
(declare (function my-cons (float string) list) )
...
The problem is that the argument type declaration here is of absolutely
no use.
...
It would be more valuable as far as I can see to say that a
(function (float string) list)
is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?
In Maclisp, if you declared a function to take arguments (fixnum flonum),
for example, special tricks were allowed to be done with passing the arguments
without having to heap-cons them. You were required to only use this declaration
if you had made it available to the compiler at the time of compiling the function
(so that it would have done the special tricks necessary to make the external
calling sequence work). The net effect was that the function had a naive entry
point (for people who didn't know about the declaration) and a magic entry point
for people who wanted to exploit the declaration information and bypass some
setup instructions.
In order to get this effect in CL, we have only to restrict the declaration of
a function to be exactly the declaration that the function was compiled under.
That is, there are a number of possible universes we could elect to be in:
* We could allow local function declarations to just say things we know to
be true, regardless of whether they were interesting. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This would tend to thwart interesting compilations because nothing in the
declaration would tell you anything useful about how the function was compiled.
* We could allow local function declarations only if they restrict the
declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This might thwart some interesting compilations because you wouldn't know
everything about the way the function was compiled, but you'd know some
information.
* We could allow local function declarations only if they exactly match
the declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)
This would have the best chance of getting interesting compilations, I think.
* We could, as I guess Pavel is suggesting (though I lost or missed the
original mail), allow multiple declarations of the same function, in which
case the information provided would be of an entirely different nature (in
what amounts to a DEFMETHOD style) than what it's used for in the previous
three bullet items.
Presumably there are some gains to be had from this style. I have no feel for
how useful they are. An example, though, would be:
(PROCLAIM '(FUNCTION FOO (LIST) LIST))
(PROCLAIM '(FUNCTION FOO (VECTOR) VECTOR))
which would let you compile
(LENGTH (FOO (THE LIST L)))
into
(SYSTEM:LENGTH-ROUTINE-FOR-THINGS-KNOWN-TO-BE-OF-TYPE-LIST (FOO L))
[Sigh. I'd have called it SYSTEM:LIST-LENGTH, but that's taken by CLtL for
something that doesn't mean what I think of as LIST-LENGTH. A poor naming
decision if you ask me...]
* This is a placeholder to remind readers that the likelihood that this list is
exhaustive is fairly low.
This really gets at the heart of the problem, which is:
* Are declarations just for compilation or do they serve some more abstract
higher level goal (eg, "documentation").
* How important is exact-typep information vs typep information.
* How much of a modularity violation (or documentation constraint) is it to
have to know the exact conditions under which a function was compiled.
* How important are optimal compilations?
∂03-Dec-87 1042 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:42:12 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 3 Dec 87 13:41:26 EST
Received: by kali.think.com; Thu, 3 Dec 87 13:41:22 EST
Date: Thu, 3 Dec 87 13:41:22 EST
From: gls@Think.COM
Message-Id: <8712031841.AA07746@kali.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 1 Dec 87 11:25 EST <871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
Date: Tue, 1 Dec 87 11:25 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
I think the remark about aesthetics not counting at all in FORMAT is cute
but not strictly true. But since I don't have anything more consequential
to write there, I'll suggest the following compromise presentation which
(for the sake of casual readers and future historians) makes it more clear
that we're being flippant -- or at least less clear that we're being
serious...
Aesthetics:
``Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele, Jr.
I would accept this friendly amendment.
--Guy
∂03-Dec-87 1059 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:58:54 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA20506; Thu, 3 Dec 87 11:57:15 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA21459; Thu, 3 Dec 87 11:57:05 MST
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712031857.AA21459@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: Masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu,
sandra%orion@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 3 Dec 87 12:52 EST
One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. Back when we were trying to
implement a CL compatibility package in PSL, we wanted to do the
matching of actual arguments to lambda variables at compile-time so we
could use the EXPR call protocol instead of the much slower NEXPR
protocol. (Basically, we had an EXPR entry point for every function
with a 1-1 correspondence between actual arguments and lambda
variables.) The problem is, you couldn't do the transformation on a
call unless you already knew something about the lambda list for the
function.
I agree that the argument type business is confusing and not very useful
in its current state. I'd like to say that
(LOCALLY (DECLARE (FTYPE (FUNCTION (INTEGER INTEGER) INTEGER) +))
(+ X Y))
is equivalent to
(THE INTEGER (+ (THE INTEGER X) (THE INTEGER Y)))
but I'm not sure that's exactly what CLtL is getting at.
-Sandra
-------
∂03-Dec-87 1059 CL-Cleanup-mailer CL-CLEANUP membership
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87 10:59:19 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 3 Dec 87 13:58:48 EST
Received: by kali.think.com; Thu, 3 Dec 87 13:58:44 EST
Date: Thu, 3 Dec 87 13:58:44 EST
From: gls@Think.COM
Message-Id: <8712031858.AA07850@kali.think.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 30 Nov 87 11:39 PST <871130-114008-117@Xerox>
Subject: CL-CLEANUP membership
I am sending this message merely to remark that, inasmuch as my
name *was* on the list Mathis sent out, it is necessary for this
message to contain the word "axolotl" in order to distinguish it
from valid replies to Larry's request.
Sorry, but I could not resist.
--Guy
∂03-Dec-87 1123 CL-Cleanup-mailer FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I'd like to reiterate what Pavel said: the declaration
(declare (function my-cons (float string) list) )
means that the function MY-CONS accepts two arguments, the first at least
of the type FLOAT (it can be a more general type), and the second at least
of the type STRING; it returns one value which is of the type LIST (it
could be more specific).
Unfortunately, it does not mean that if the two arguments are of types
FLOAT and STRING then the result is of type LIST, which would be
useful.
Lucid has a variant of this called RESTRICTIVE-FTYPE (or something),
which would mean MY-CONS assumes it receives two arguments of types
FLOAT and STRING and produces something of type LIST.
See page 47 (CLtL), the last complete paragraph, to see this.
-rpg-
∂03-Dec-87 1215 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 87 12:15:27 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 301485; Thu 3-Dec-87 14:17:50 EST
Date: Thu, 3 Dec 87 14:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: sandra%orion@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@xerox.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: <8712031857.AA21459@orion.utah.edu>
Message-ID: <871203141725.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. ...
Thanks for remembering to mention this issue. It pops into my head from time to time
and then I always forget it before I get to the console.
Yes, the same style of issues as I raised in my last message applies to argument
number. eg, if I did
(PROCLAIM '(FUNCTION FOO (NUMBER NUMBER) NUMBER))
(DEFUN FOO (X Y) (+ X Y))
and later did:
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM &REST (LIST T)) FIXNUM)) ... (FOO ...) ...)
would I be within reason? ie, is there semantic impact to the &REST which goes beyond
type declaring the rest of the arguments to be of type T? Am I also declaring that the
function was in fact compiled believing that a &REST style argument pickup was used
(and at the same point as I've specified it here). What about:
(PROCLAIM '(FUNCTION FOO (NUMBER &REST (LIST NUMBER)) NUMBER))
(DEFUN FOO (X &REST Y) (APPLY #'+ X Y))
and then later
(LOCALLY (DECLARE (FUNCTION FOO (NUMBER NUMBER &REST (LIST NUMBER)) NUMBER))
... (FOO ...at least two arguments...) ...)
In my CL conversion of Macsyma, I threw out all the *LEXPR declarations because
CL couldn't make any use of them and they were just clutter. (And they'd be trivial
to re-conjure if they were ever needed.) But I felt funny as I did it because I did
know I was throwing away information that would be interesting to some compilers
and that seemed sad, so I definitely agree that one way or another, this is a real
issue.
∂03-Dec-87 1331 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 13:31:12 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Dec 87 16:30:32-EST
Date: Thu, 3 Dec 1987 16:30 EST
Message-ID: <RAM.12355605918.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa@XEROX.COM, sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 3 Dec 1987 12:52-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
My compiler cleanup proposal addresses a number of the issues being
discussed here. We already went around once on cl-cleanup about the
meaning function type.
In my initial proposal, I had assumed a strict interpretation of
function type. It was pointed out to me, that not only is CLTL very
clear about its non-restrictive interpretation, it is also very
difficult to use a strict interpretation within the framework of the
current type system.
Basically, the problem is that if you think about "function type
declarations" as being declarations about the type of the object which
is the function, then it isn't possible to use a strict
interpretation. If you attempt to do so, then there will be cases
where a type declaration is necessary for a program to be correct, and
removing declarations can cause a program to be incorrect. In
addition to problems with defining where declarations are necessary,
requiring declarations is also clearly in conflict with the stated
goals for declarations in Common Lisp.
Basically, the reason for this non-intuitive result is that a
declaration of a function's type actually makes a statement about what
definitions are legal, rather than what calls are legal. What a
compiler really wants to know is what calls are legal.
The solution I suggest in my proposal is to introduce a mechanism that
allows arbitrary information about a function definition to be bound
at compile time. You don't declare the function type, you just define
the function, with any appropriate argument type declarations.
Since you have asserted that calls to the function can be bound at
compile time, the compiler can apply any assertions on the formal
parameters to the actual parameters and use type information derived
from the definition as the type of the call result.
Early-binding of function names also allows many other optimizations
such as "inline expansion" and "block compilation".
Before people flame uncotrollably about the horror of static function
binding in Lisp, I will point out that I don't propose that static
function binding be required, or even that it necessarily be the
default. It is also worth noting that the extent to which static
binding is actually done once it has been allowed is an implementation
decision. Declaring static binding doesn't necessarily prevent
incremental redefintion or reduce safety, it might only cause better
compiler warnings to be generated.
If this capability exists, then function type declarations (and
function types) are more useless than they currently are (if that is
even possible).
Rob
P.S. My proposal is <ram>cprop.txt on c.cs.cmu.edu
∂04-Dec-87 1430 CL-Cleanup-mailer Issue: LAST-N (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Dec 87 14:30:43 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 295555; Fri 4-Dec-87 16:49:13 EST
Date: Fri, 4 Dec 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
People always ask why LAST returns a cons and not an element.
BUTLAST takes an argument N but LAST does not.
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
It is an error if N is negative or L is circular.
If N is equal to the number of cons cells in the list L, then the atom which
terminates the list L is returned.
If N is greater than the number of cons cells in the list L, then it is an
error if the list is not a proper list. If in this case the list is a proper
list, then L is returned.
Test Cases:
(LAST '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)
(LAST '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)
(LAST '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)
(LAST '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()
(LAST '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()
(LAST '(A B C)) => (C)
(BUTLAST '(A B C)) => (A B)
(LAST '(A . B) 0) => B
(LAST '(A . B) 1) => (A . B)
(LAST '(A . B) 2) is an error.
Rationale:
BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.
This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.
Current Practice:
Probably nobody does this.
Adoption Cost:
Very slight. The following code would suffice:
(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))
Some implementations might want to provide compiler optimizations for
the N=1 case.
Benefits:
This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.
Conversion Cost:
None. This is an upward compatible extension.
Aesthetics:
This would make things a little prettier.
Discussion:
This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too. Pitman thinks
it's a nice idea.
∂04-Dec-87 1449 CL-Cleanup-mailer Issue: LAST-N (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 14:49:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 4 Dec 87 17:49:16-EST
Date: Fri, 4 Dec 1987 17:49 EST
Message-ID: <FAHLMAN.12355882409.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: LAST-N (Version 1)
In-reply-to: Msg of 4 Dec 1987 16:49-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Seems harmless enough... No strong opinion one way or the other.
-- Scott
∂04-Dec-87 1535 CL-Cleanup-mailer Issue: LAST-N (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Dec 87 15:35:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 295702; Fri 4-Dec-87 18:35:08 EST
Date: Fri, 4 Dec 87 18:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19871204233526.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 4 Dec 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Issue: LAST-N
References: LAST (p267)
Category: ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):
Allow LAST to take an optional argument N, saying how many cells to return.
You should say explicitly that the default for N is 1.
The following two paragraphs cannot be correct. For example, think about
(last '(a)), which you are saying returns nil.
If N is equal to the number of cons cells in the list L, then the atom which
terminates the list L is returned.
If N is greater than the number of cons cells in the list L, then it is an
error if the list is not a proper list. If in this case the list is a proper
list, then L is returned.
I think what you really mean is
If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in
the list L, then the result is L.
This correction makes it consistent with your examples.
With these corrections, I don't oppose the proposal. I'm not strongly in
favor of it, since I put less priority on enhancements than on correcting
mistakes in what we've got already. I'll favor it if others do.
∂04-Dec-87 1729 CL-Cleanup-mailer Re: Issue: LAST-N (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 17:28:54 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 DEC 87 15:35:33 PST
Date: 4 Dec 87 15:35 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: LAST-N (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 4 Dec 87 16:49 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871204-153533-228@Xerox>
I don't much care. It basically looks OK.
-- Andy. --
∂04-Dec-87 1729 CL-Cleanup-mailer Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 17:29:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 DEC 87 15:38:37 PST
Date: 4 Dec 87 15:38 PST
From: Daniels.pa@Xerox.COM
Subject: Introduction
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871204-153837-228@Xerox>
Hello all. I'm a senior developer with Xerox's AI group. I'm also one of the two
members of the error system subgroup. I'm on this particular list mainly to keep
an eye on the accepted cleanups and changes and make sure our implementation
conforms.
For the most part, other people seem to adequately cover the space of things
I've wanted to say, so you're not likely to see much mail from me.
-- Andy. --
∂05-Dec-87 0001 CL-Cleanup-mailer Introduction
Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 5 Dec 87 00:01:45 PST
Received: from unido.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA28402; Sat, 5 Dec 87 03:01:28 EST
Received: by unido.uucp with uucp;
Sat, 5 Dec 87 08:30:41 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@uunet.UU.NET>
Date: Fri, 4 Dec 87 16:12:40 -0100
Message-Id: <8712041512.AA03656@ztivax.uucp>
Received: by ztivax.uucp; Fri, 4 Dec 87 16:12:40 -0100
To: CL-Cleanup@sail.stanford.edu
Subject: Introduction
I am Dieter Kolb of Siemens AG, West Germany. In my group we
are developing a Common LISP system for Siemens computers.
I am also member of the EuLisp group in Europe.
I am following the conversion on CL-Cleanup to get information
for our implementation activities as well as to provide discussion
contributions based on our experience with the language.
Dieter Kolb
Siemens AG
ZTI SOF 23
Otto Hahn Ring 6
D-8000 Munich 83
Phone: +49-89-636-2386
ARPA net address: unido!ztivax!kolb@SEISMO.CSS.GOV
Xerox Internet address: kolb:ztisof:siemens
∂06-Dec-87 1424 CL-Cleanup-mailer Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Dec 87 14:24:29 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 296206; Sun 6-Dec-87 17:14:51 EST
Date: Sun, 6 Dec 87 17:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DRIBBLE-TECHNIQUE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871206171357.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DRIBBLE-TECHNIQUE
References: DRIBBLE (p443)
Category: CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The intent and effect of DRIBBLE is not very clearly specified.
Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):
Clarify that DRIBBLE is intended primarily for interactive debugging
and that its effect cannot be relied upon from programs.
Test Case:
#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))
#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))
Rationale:
Users of DRIBBLE have been surprised about how differently DRIBBLE
behaves in different implementations. This makes the status quo
much more explicit and will lead to less surprise.
Current Practice:
Some implementations implement DRIBBLE as a function which simply
assigns streams such as *STANDARD-OUTPUT* to broadcast streams
(or the approximate equivalent thereof). Even within this camp,
there is not widespread agreement about which streams are affected.
However, typically test case #1 will capture the output of (PRINT 'FOO)
in the file "temp" and will execute (PRINT 'BAR) but not capture its
output.
Some implementations (eg, Symbolics) push to a recursive command
loop when DRIBBLE is called with an argument, and return from that
command loop when DRIBBLE is called with no argument. In these
implementations, test case #1 will enter a recursive command loop
upon the first call to DRIBBLE and will not execute the (PRINT 'FOO)
until (DRIBBLE) is done interactively. When the second (DRIBBLE)
in test case #1 is executed, DRIBBLE will complain that output is
not currently being recorded. In test case #2, the output of
(PRINT 'FOO) will be captured, but the form (PRINT 'BAR) will never
be executed because (DRIBBLE) does not return normally (it throws).
Adoption Cost:
None. This is just a clarification.
Benefits:
Users will be aware that they cannot rely on DRIBBLE in portable code.
Conversion Cost:
Effectively none. Anyone who currently uses DRIBBLE in code that is
believed to be portable is kidding himself. If such code works in some
implementations, it can continue to work.
Aesthetics:
Since this is a clarification, there is no significant change to
the aesthetics.
Discussion:
Pitman wrote this proposal as a straw man so that CL-Cleanup would have
the issue on the books for explicit discussion.
∂06-Dec-87 1435 CL-Cleanup-mailer Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Dec 87 14:35:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 DEC 87 14:35:09 PST
Date: 6 Dec 87 14:28 PST
From: pedersen.pa@Xerox.COM
Subject: Introduction
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871206-143509-2198@Xerox>
Hi,
My name is Jan Pedersen and I work for Xerox as a Xerox Lisp developer and as a
member of the Natural Language group at PARC. I'm on the CL-Cleanup list as an
observer since it is high priority here to maintain strict adherance with the
Common Lisp specification.
J.P.
∂07-Dec-87 1643 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Dec 87 16:43:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 87 15:23:50 PST
Date: 7 Dec 87 14:40 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Thu, 3 Dec 87 16:30 EST
To: Ram@C.CS.CMU.EDU
cc: KMP@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa@Xerox.COM, sandra%orion@CS.UTAH.EDU
Message-ID: <871207-152350-3643@Xerox>
Ram: I've scanned your latest proposal, but it still doesn't seem to address the
minor issue at hand here:
What does
(declare (function (integer integer) t) foo)
imply?
We've discussed what it could mean, what it should mean, what CLtL says it
means, but I'd to hear about current practice. What, if anything, do current
implementations do with such declarations? Do any implementations pay attention
to the types of arguments in function declarations?
∂07-Dec-87 2038 CL-Cleanup-mailer [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 20:38:02 PST
Received: by labrea.stanford.edu; Mon, 7 Dec 87 20:31:59 PST
Received: from bhopal.lucid.com by edsel id AA02700g; Mon, 7 Dec 87 18:22:09 PST
Received: by bhopal id AA01347g; Mon, 7 Dec 87 18:22:31 PST
Date: Mon, 7 Dec 87 18:22:31 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8712080222.AA01347@bhopal.lucid.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 30 Nov 87 12:19 EST <19871130171930.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
re: It [density] can also be deduced from the definitions of array-total-size
and array-row-major-index, because the range of array-row-major-index's
answer is defined to be a range of integers that contains just enough
members to supply a value for each subscript set, with no gaps.
I think my previous note mentioned that density in storage isn't actually
required by this bijective mapping -- it would only do so if the output
of array-row-major-index were required to be a memory index.
Perhaps one couldn't imagine any other meaning for array-row-major-index
other than "index offset from base memory location"; but CLtL doesn't
say this now, and I can certainly think of alternative representations
which would reinject the "linearized" index into the multi-dimensional
format simply in order to preserve the documented property.
If any clarification is necessary, then it ought to take into account
the AREF-1D proposal, which would raise some efficiency questions if the
bijective mapping weren't "index-offset" memory access.
-- JonL --
∂07-Dec-87 2310 CL-Cleanup-mailer introduction
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:10:18 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa03665; 8 Dec 87 0:33 EST
Received: from csc.ti.com by RELAY.CS.NET id ac17859; 8 Dec 87 0:29 EST
Received: from ERDOS by tilde id AA29927; Mon, 7 Dec 87 19:20:20 CST
To: cl-cleanup@SAIL.STANFORD.EDU
Cc:
From: HAUG%erdos.csc.ti.com@RELAY.CS.NET
Subject: introduction
Date: 7-Dec-87 19:15:55
Sender: HAUG%erdos.csc.ti.com@RELAY.CS.NET
Message-Id: <HAUG.2774913353@ERDOS>
My name is David Haug and I work for the Symbolic Computing group at TI
and did a lot of work for the Explorer project. My participation in the
CL-cleanup group has been as an observer to keep track of changes to
the language. However, my observer status will change if I am
sufficiently stirred.
--------- DHaug
∂07-Dec-87 2315 CL-Cleanup-mailer Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:15:06 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Dec 87 01:45:15-EST
Date: Sun, 6 Dec 1987 22:57 EST
Message-ID: <FAHLMAN.12356462749.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: DRIBBLE-TECHNIQUE (Version 1)
In-reply-to: Msg of 6 Dec 1987 17:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE.
I'm not sure exactly what KMP means by stating that this proposal is a
straw man, but I like it. I think that it was a mistake to put dribble
into the manual, and that we should just tell users that it differs from
system to system. I don't think that there's any hope of getting a
standard that makes sense on editor-top-level systems, dumb
Read-Eval-Print systems, and all the flavors in between, so we should
just punt on this.
The only advantage of mentioning DRIBBLE in the standard at all is that
users know what name to look up in any given system to get this general
sort of functionality.
-- Scott
∂07-Dec-87 2328 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:24:56 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01737; Mon, 7 Dec 87 18:37:22 EST
Message-Id: <8712072337.AA01737@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Date: Mon, 07 Dec 87 18:37:19 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261),
SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION,
SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR,
NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
(pp. 280-281)
Category: ADDITION
Edit history: Version 1 by Pierson 12/5/87
Issue: For Internal Discussion
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword.
Test Cases/Examples:
Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:
(REDUCE #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (+ (PERSON-AGE X) (PERSON-AGE Y)))
ASTROS)
If this proposal is adopted, the same result could be obtained with:
(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)
Rationale:
This proposal brings REDUCE into line with the rest of the sequence
and list modifying and searching functions at the cost of slightly
blurring the meaning of :KEY arguments.
Current practice:
Does anyone currently support this as an extension?
Cost to Implementors:
This will require most implementations to make a trivial modification
to REDUCE. Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).
Cost to Users:
None, this is an upward compatible extension.
Cost of non-Adoption:
REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.
Benefits:
REDUCE will become easier to use on sequences of complex objects. It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.
Aesthetics:
Slightly damaged. All :KEY arguments are currently defined to be used
for predicates, this proposal will implicitly broaden :KEY to support
general extraction for any purpose.
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
∂08-Dec-87 0021 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 00:20:56 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01767; Mon, 7 Dec 87 18:40:50 EST
Message-Id: <8712072340.AA01767@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Date: Mon, 07 Dec 87 18:40:46 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: DISASSEMBLE-SIDE-EFFECT
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 12/2/87
Status: For Internal Discussion
Problem description:
The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.". The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...". Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).
Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):
Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(DISASSEMBLE 'F)
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)
This code will return NIL if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Rationale:
Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.
Current practice:
Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it. [[This is from an informal survey at
the last meeting; please correct any mistakes.]]
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
Benefits:
DISASSEMBLE will become the predictable debugging function it was
meant to be.
Aesthetics:
Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
Discussion:
∂08-Dec-87 0728 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 07:28:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Dec 87 10:27:51-EST
Date: Tue, 8 Dec 1987 10:27 EST
Message-ID: <FAHLMAN.12356850608.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Dan L. Pierson" <pierson@MULTIMAX.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Msg of 7 Dec 1987 18:40-EST from Dan L. Pierson <pierson at multimax.ARPA>
I support DO-NOT-INSTALL.
∂08-Dec-87 0857 CL-Cleanup-mailer Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 08:51:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 08:41:54 PST
Date: 8 Dec 87 08:41 PST
From: Brotsky.pa@Xerox.COM
Subject: Introduction
To: CL-Cleanup@sail.stanford.edu
cc: Brotsky.pa@Xerox.COM
Message-ID: <871208-084154-4763@Xerox>
I'm Dan Brotsky. I used to be at the MIT AI Lab and now I'm at Xerox PARC. I've
been fighting for years to clean up the entire first half of the alphabet,
concentrating so far primarily on the letters A, B, and M. So (as you might
imagine) I'm quite excited about participating in an effort directed at the
other 10.
dan
∂08-Dec-87 0937 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 09:37:06 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297870; Tue 8-Dec-87 12:36:31 EST
Date: Tue, 8 Dec 87 12:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: pierson@MULTIMAX.ARPA
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8712072340.AA01767@multimax.ARPA>
Message-ID: <871208123627.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I mostly approve of the proposal contained in this write-up, though I have
some specific comments that I think should be addressed...
Date: Mon, 07 Dec 87 18:40:46 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: DISASSEMBLE-SIDE-EFFECT
...
Test Cases/Examples:
(DEFUN F (A) (1+ A))
(DISASSEMBLE 'F)
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)
This code will return NIL if this proposal is adopted. Some current
implementations will return T, some will return NIL.
...
This isn't quite the right test case. Our Cloe implementation will return
T if this proposal is adopted because it is a compiled-only implementation.
I suggest:
(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))
I believe this will return T for all implementations if this proposal is
adopted and might return either T or NIL right now.
Current practice:
Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it. [[This is from an informal survey at
the last meeting; please correct any mistakes.]]
I checked the various Symbolics implementations, and I guess my stated
beliefs in this informal survey were wrong. We don't install it so should
be listed with Lucid and KCL. [Actually, we have three situations. Our
released system signals an error, our development system compiles a dummy
function and does not install the definition, and our Cloe system (a CL
for the 80386) is a compiled-only implementation so this issue is not
meaningful.
...
Aesthetics:
Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
...
I would say "Some who worried..." rather than "Those who thought...".
∂08-Dec-87 0939 CL-Cleanup-mailer Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 09:38:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 09:39:02 PST
Date: 8 Dec 87 09:38 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun, 6 Dec
87 22:57 EST
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871208-093902-4884@Xerox>
I agree that DRIBBLE should be explicitly vague.
-- Andy. --
∂08-Dec-87 0948 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 09:48:22 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297885; Tue 8-Dec-87 12:47:14 EST
Date: Tue, 8 Dec 87 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
To: pierson@MULTIMAX.ARPA
cc: cl-cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8712072337.AA01737@multimax.ARPA>
Message-ID: <871208124709.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I mostly support the contained proposal, but have a number of specific comments...
Date: Mon, 07 Dec 87 18:37:19 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Issue: REDUCE-ARGUMENT-EXTRACTION
References: REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261),
SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION,
SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR,
NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
(pp. 280-281)
I think this references list will scare people voting. I think the references is
intended to give people an idea of how sweeping the change is. If we feel strongly
that this isn't enough, we might want to have both a references and a cross-references
field. But for now I'd just leave the references as
REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut example (pp. 312-313)
and drop the rest.
Category: ADDITION
Edit history: Version 1 by Pierson 12/5/87
Issue: For Internal Discussion
Problem description:
REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword.
This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.
Test Cases/Examples:
...
This is a good example.
Rationale:
This proposal brings REDUCE into line with the rest of the sequence
and list modifying and searching functions at the cost of slightly
blurring the meaning of :KEY arguments.
I would not mention the discussion of the name :KEY here at all. Leave it for
the discussion because it's confusing unless presented in full form, and it's
too much work to present here. Maybe just say:
This proposal makes many common situations where REDUCE would be useful
much less cumbersome.
Current practice:
Does anyone currently support this as an extension?
...
It's not worth mentioning in the proposal, but for your general information
so you don't think we didn't notice the question, Symbolics does not currently
support this.
Aesthetics:
Slightly damaged. All :KEY arguments are currently defined to be used
for predicates, this proposal will implicitly broaden :KEY to support
general extraction for any purpose.
I might say "Slightly damaged in one way..." and then have a second paragraph
that says "Slightly improved in another way. Many common situations where
REDUCE could be used would be easier to write and easier to later read."
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.
∂08-Dec-87 1121 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 11:21:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 11:18:30 PST
Date: 8 Dec 87 11:18 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:40:46 EST
To: cl-cleanup@sail.stanford.edu
cc: pierson@multimax.ARPA
Message-ID: <871208-111830-5089@Xerox>
I support DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL. BTW, Xerox Lisp does not
install the compiled definition.
-- Andy. --
∂08-Dec-87 1123 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 11:22:50 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 14:22:06-EST
Date: Tue, 8 Dec 1987 14:21 EST
Message-ID: <RAM.12356893261.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA,
sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 7 Dec 1987 17:40-EST from Masinter.pa at Xerox.COM
Date: Monday, 7 December 1987 17:40-EST
From: Masinter.pa at Xerox.COM
To: Ram at C.CS.CMU.EDU
cc: KMP at SCRC-STONY-BROOK.ARPA, cl-cleanup at SAIL.STANFORD.EDU,
Masinter.pa at Xerox.COM, sandra%orion at CS.UTAH.EDU
Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
[...] What does (declare (function (integer integer) t) foo) imply?
We've discussed what it could mean, what it should mean, what CLtL
says it means, but I'd to hear about current practice. What, if
anything, do current implementations do with such declarations? Do
any implementations pay attention to the types of arguments in
function declarations?
Our current compiler totally ignores function type declarations.
I am working on a new compiler that currently gives function type
declarations a strict interpretation, i.e. the function must be called
only with two integer arguments. (I suspect that this is like the
RESTRICTIVE-FTYPE declarations that someone from Lucid mentioned.) At
least as an interpretation for FTYPE, this is clearly wrong. I intend
to at least rename this declaration, and perhaps entirely flush it as
a user-visible facility.
I think that we should either entirely flush the concept of "function
types" or change the theory behind them. The CLtL interpretation is
well-defined, but not very useful. The intuitive strict
interpretation is useful, but is not a type declaration, at least in
the sense used in CLtL.
The restrictive interpretation can be modeled as a sort of magic
syntactic shorthand for a bunch of THE declarations at the call site:
(the t (foo (the integer x) (the integer y)))
But under this interpretation, a "function type" isn't a type at all,
since it isn't in any sense the type of the function object being
called. It wouldn't be meaningful to declare a variable or value to
have a function type. A "function type declaration" would be a piece
of magic recognized by the implementation that constrains calls to a
particular function variable.
If we did this, then the concept of a "function type specifier" should
be flushed, since "function types" can't be used in any of the ways
real types can. The "function type" syntax would become part of the
syntax peculiar to a "function type declaration". (A minor beneficial
side-effect is that it would make obvious the restriction on function
types in TYPEP.)
One problem that I have with this interpretation is that it makes the
evaluation of the functional position even more peculiar than it
already is. Since a "function type declaration" would be purely
syntactic, it would only take effect when there was a syntactic match,
i.e. an obvious normal call to a declared function variable. It would
probably be incorrect to do this transformation:
(funcall #'foo x y) ==>
(the t (funcall #'foo (the integer x) (the integer y))))
Rob
∂08-Dec-87 1231 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 12:31:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 12:05:20 PST
Date: 8 Dec 87 12:05 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:37:19 EST
To: pierson@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208-120520-5164@Xerox>
In general I favor this proposal, but it needs some cleaning up before I'm happy
with it.
It cleans up a non-uniformity in the arguments passed to the reduction function
that has always bothered me: If there is no initial value, the first call to the
reduction function receives two sequence elements; successive calls receive an
accumulated value and a sequence element. The order of these arguments depends
on :FROM-END as well. I've taken to providing an :INITIAL-VALUE argument just to
avoid cluttering up the reduction function with the hair to handle all this.
In fact, because of this nonsense, the example given in the proposal only works
for sequences with exactly two elements. A more correct example is
(reduce #'(lambda (x y) (+ x (person-age y))) astros :initial-value 0)
NB: Since there's an initial value you can dispense with the &optional, and the
first argument to the reduction function is now always the accumulated value.
Even with this new example, I think I'd still rather write
(reduce #'+ astros :key #'person-age)
The intent of the code seems clearer to me here.
There are a few details missing from the proposal.
1) The key-fn is never applied to the initial value, if any.
2) The wording in CLtL about how the initial value participates in the reduction
will have to be changed a bit.
3) If the specified subsequence contains exactly one element, no initial value
is given, and a key-fn has been provided, it is applied to that element and the
resulting value is returned.
If people are unhappy about using the :KEY keyword for this purpose because of
the aesthetic problems, I'm happy to entertain suggestions for another keyword
to use instead.
-- Andy. --
∂08-Dec-87 1334 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 13:34:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 13:19:30 PST
Date: 8 Dec 87 12:36 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:37:19 EST
To: pierson@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208-131930-5290@Xerox>
This is a good writeup. I think we should add the alternative form
(reduce #'+ (mapcar #'person-age astros))
as the most natural equivalence; the stuff with the &optional arguments is
arcane and bogus in cases where there is an initial value.
I think that it is true that
(reduce <fn> sequence :key <key-fn>) = (reduce <fn> (mapcar <key-fn> sequence))
except of course in the matter of order of evaluation.
∂08-Dec-87 1418 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 14:18:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 14:12:24 PST
Date: 8 Dec 87 14:10 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Masinter.pa's message of 8 Dec 87 12:36 PST
To: Masinter.pa@Xerox.COM
cc: pierson@multimax.ARPA, cl-cleanup@sail.stanford.edu
Message-ID: <871208-141224-5386@Xerox>
Masinter writes:
I think that it is true that
(reduce <fn> sequence :key <key-fn>) = (reduce <fn> (mapcar
<key-fn> sequence))
except of course in the matter of order of evaluation.
Well, that and the fact that MAPCAR doesn't work on arrays...
-- Andy. --
∂08-Dec-87 1620 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:16:41 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 16:05:38 PST
Date: 8 Dec 87 15:22 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 8 Dec 87 12:36 EST
To: cl-cleanup@sail.stanford.edu
Message-ID: <871208-160538-5539@Xerox>
I think we should take a step back and ask what the place of DISASSEMBLE, ED,
TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard. These are
things for which constructing a denotational semantics is not feasible, cann't
be easily tested with a validation suites, etc.
I think a more global change of status for these is called for; I'd propose that
the ANSI Standard should say something like:
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
Once we move away from conformance and standard into recommendation, we might
actually be more able to make better progress recommending, for example, that
systems call their GC function (GC) and their exit function (EXIT) etc.
Opinions?
∂08-Dec-87 1644 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:44:47 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA01634; Tue, 8 Dec 87 16:50:18 EST
Message-Id: <8712082150.AA01634@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-Reply-To: Your message of Tue, 08 Dec 87 12:47:00 -0500.
<871208124709.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 08 Dec 87 16:50:09 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
Date: Tue, 8 Dec 87 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Discussion:
Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY. No one has objected
to this change in the recent round of discussions.
There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.
To quote from CLtL page 246: "If an operation tests elements of a
sequence in any manner, the keyword argument :KEY, if not NIL, should
be function of one argument that will extract from an element the part
to be tested in place of the whole element."
This seems like a definition of :KEY to me, though I will cheerfully
agree that it doesn't specify that this is the only legal meaning of
:KEY.
Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):
Change the definition of REDUCE to take a :KEY keyword.
This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.
The text on page 246 is also the only place that :KEY is documented in
CLtL. However, I agree that a full description should be here both
because this is a slightly different use of :KEY and because our
standard document is likely to be more verbose than CLtL.
∂08-Dec-87 1828 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 18:28:33 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 21:28:09-EST
Date: Tue, 8 Dec 1987 21:28 EST
Message-ID: <FAHLMAN.12356970828.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Msg of 8 Dec 1987 18:22-EST from Masinter.pa at Xerox.COM
Explicitly excluding these environment thingies from the standard, and
demoing them to mere "suggested names" seems like a reasonable way to
go.
-- Scott
∂08-Dec-87 1836 CL-Cleanup-mailer Introductions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 18:36:13 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 21:35:51-EST
Date: Tue, 8 Dec 1987 21:35 EST
Message-ID: <FAHLMAN.12356972234.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Introductions
I'm Scott Fahlman of Carnegie-Mellon University, and most of you know
me, I think.
There are three other CMU people on the cleanup list, all full-time CMU
staff members who work with me in the CMU Common Lisp project (formerly
Spice Lisp). Dave McDonald and Bill Chiles are on the list mostly as
observers, making sure that we know about changes so that our
implementation can track them accurately. Chiles has also had some
dealings with the error committee. Rob Maclachlan (please note the
spelling) has been more vocal, especially on issues related to
compilation, types, and I/O.
-- Scott
∂09-Dec-87 0309 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Dec 87 03:03:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 87 03:00:06 PST
Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Tue, 8 Dec 87 14:21 EST
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871209-030006-1558@Xerox>
I think I understand and agree with most of what you say, in particular "I think
that we should either entirely flush the concept of "function types" or change
the theory behind them. The CLtL interpretation is well-defined, but not very
useful. "
There are two components to your proposal: (1) what is allowed (and what it
means), and (2) how it is described in the standard.
I like the part of your proposal which is to change the interpretation of
function declarations to mean an implicit assertion of argument and value types
(the "restrictive interpretation").
I like defining (declare (type (function (frob grid) bunker) x)) to mean
(funcall x y z) has implicitly means (the bunker (funcall (the function x)
(the frob y) (the grid z)))
I don't see, however, that there is much leverage to removing FUNCTION from the
section on type specifiers. It would do some violence to the otherwise useful
concept of
(deftype binary-arithmetic () '(function (number number) number))
to be used in
(declare (ftype binary-arithmetic x y z)) .
I don't see at all that (funcall #'foo x y) doesn't mean (the t (funcall #'foo
(the integer x) (the integer y)))) given (declare (function foo (integer
integer) t)).
In the type propagation rules, you can transform funcall and apply expressions
using the asserted value of the function argument, and the asserted value type
of #'name is derived from the asserted ftype of name.
In this interpretation, AND would distribute nicely,
Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that
(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).
(OR doesn't distribute as nicely, e.g., given (declare (ftype (or (function (s1
t1) v1) (function (s2 t2) v2)) foo)), there isn't a simple way to describe the
type assertions made for (foo x y).
We might even want to explicitly allow FUNCTION declarations in THE
expressions, as in
(funcall (the binary-arithmetic x) y z).
∂09-Dec-87 0702 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 07:02:20 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA09306; Wed, 9 Dec 87 08:00:52 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA16131; Wed, 9 Dec 87 08:00:48 MST
Date: Wed, 9 Dec 87 08:00:48 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712091500.AA16131@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@xerox.com
Cc: Ram@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST
Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM
Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that
(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).
I disagree. The DECLARE should shadow the PROCLAIM; see p. 156 of
CLtL. Or is there another proposal in the works to change declaration
shadowing as well? :-)
-Sandra
-------
∂09-Dec-87 0729 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 07:29:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 9 Dec 87 10:28:51-EST
Date: Wed, 9 Dec 1987 10:28 EST
Message-ID: <FAHLMAN.12357112955.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-DECLARATION issues
In-reply-to: Msg of 9 Dec 1987 05:59-EST from Masinter.pa at Xerox.COM
Seems to me that we're trying to overload the type definition for
FUNCTION in ways that are not altogether consistent. I'd suggest the
following:
1. Leave the FUNCTION type specifier alone. It's not terribly useful in
its non-restrictive form, but it is harmless and it does fit in with the
rest of the type system. (Of course, we would make it a full-fledged
type-specifier as discussed in the FUNCTION-TYPE proposal.)
2. Add an extended form for the LIST type specifier so that one can
indicate element type and, perhaps, length. This can be used to say
something useful about rest-args, without having to put in ugly special
syntax for this.
3. Add a new declaration/proclamation, distinct from TYPE, by which
users can tell the compiler restrictive things about what a given
function will accept and what it will return. This notation can be set
up so that you can say things like "if all args are integer, the result
will be" and "if the second arg is spaceship, the result will be
Martian". Obviously this bit will require some careful design so that
we can make it maximally expressive and minimally confusing. I don't
have a proposal ready; maybe Rob does.
4. Let me toss in here a related idea by Dave Touretzky that I've been
waiting to introduce whenever the time is right for a new batch of
issues: the RESTRICT declaration/proclamation. Basically, (DECLARE
(RESTRICT type1 type2)) says that, within the extent covered by this
declaration, anything that is of type1 is guaranteed to be of type2 as
well, where type2 is generally more restrictive. One could say
(RESTRICT NUMBER (INTEGER -1024 1024)), which tells the compiler that
any time it can prove something is a number, it can assume it is a
fixnum. In some contexts, this can replace about six dozen THE
forms. Users find it very awkward to say things like
(the (integer -1024 1024) (+ (the (integer -1024 1024) x)
(the (integer -1024 1024) y))
..yet often that is the only portable way to assure the compiler that it
can generate fixnum-only code on most machines.
The reson I bring up RESTRICT at this time is that I think the function
restriction mentioned in point 3 is related to this. Maybe it should be
called RESTRICT-CALL or something.
-- Scott
∂09-Dec-87 0848 CL-Cleanup-mailer Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87 08:48:03 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA05595; Wed, 9 Dec 87 11:51:24 EST
Message-Id: <8712091651.AA05595@multimax.ARPA>
To: Daniels.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-Reply-To: Your message of 08 Dec 87 14:10:00 -0800.
<871208-141224-5386@Xerox>
Date: Wed, 09 Dec 87 11:51:12 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Masinter writes:
I think that it is true that
(reduce <fn> sequence :key <key-fn>) = (reduce <fn> (mapcar
<key-fn> sequence))
except of course in the matter of order of evaluation.
Well, that and the fact that MAPCAR doesn't work on arrays...
Make that:
(reduce <fn> sequence :key <key-fn>) =
(reduce <fn> (map 'list <key-fn> sequence))
Feel free to replace the "'list" with your favorite sequence type.
I'll change REDUCE-ARGUMENT-EXTRACTION to use this construct as the
present case. You're absolutely right that my previous code was badly
broken and attempts to fix it up produce a real mess. This almost
makes it interesting because the result is as cons-efficient as the
proposed new feature, while the mapping approach builds a whole new,
unecessary structure.
∂09-Dec-87 0955 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87 09:55:08 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA06214; Wed, 9 Dec 87 12:58:47 EST
Message-Id: <8712091758.AA06214@multimax.ARPA>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-Reply-To: Your message of 08 Dec 87 15:22:00 -0800.
<871208-160538-5539@Xerox>
Date: Wed, 09 Dec 87 12:58:41 EST
From: Dan L. Pierson <pierson@multimax.ARPA>
From: Masinter.pa@Xerox.COM
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
This approach makes a lot of sense, but I think we need to give
somewhat more guidance than just a list of names. We need something
along the lines of:
"The following are suggested features for a ANSI Common Lisp
programming environment. No conforming implementation is required to
support any of these features. However all implementations must
document which of these features they support and must adhere to the
following guidelines for the features they do support. No portable
ANSI Common Lisp program can rely on the behavior of these functions,
because the behavior is sepcifically not specified in the standard."
This would be followed by a set of guidelines that:
1. Guarantee that, for example, ED invokes some sort of
editor.
2. Provide some of the CLtL standard interfaces so that
people porting their programs to a new implementation
will have a fighting chance at simple use of features
TRACE and DRIBBLE without reading the manual.
The second point is important. I was recently a developer at a
software house doing more than 10 simultaneous ports. Each port was
handled by one or more junior porters and developers only got called
in when problems happened. In this sort of environment, the last
thing you want to do is spend an hour or few reading manuals before
looking at the problem.
This approach is sort of like the one take by the FORTH folks for the
Forth-83 standard. They divided Forth up into: the required words,
the optional words with mandatory definitions, and suggested (or were
they experimental) extentions.
∂10-Dec-87 2311 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Dec 87 23:10:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 87 23:10:38 PST
Date: 10 Dec 87 23:10 PST
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@Sail.Stanford.EDU
Subject: Cleanup issues from Japanese technical working group
Message-ID: <871210-231038-2589@Xerox>
I asked for the list of open Common Lisp issues from the JEIDA technical working
group. This is their list.
I've added some comments in <<brackets>>. Some of these will require separate
issues, while many are already being addressed.
----- Begin Forwarded Messages -----
Return-Path: <@RELAY.CS.NET:yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Message-Id: <8712101502.AA05475@tutics.tut.junet>
Date: Thu, 10 Dec 87 15:02:57 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@utokyo-relay.CSNET>
To: Masinter.pa
Subject: Re: US work on List standards
Question and Answers about Common Lisp. (Revised)
Q: Michiaki Yasumura (Hitachi)
A: TG/A members
[nn.nn.nn] indicates section numbers in CLtL
*******************************************************************
The following subjects should be clarified.
*******************************************************************
1) CLtL says nothing about whether structure or array is self evaluating
form. [5.1.1]
It is suggested that not only numbers, characters, and bit-vectors,
but also structures, arrays, vectors, packages be self-evaluating forms.
Yuasa: There may possibly be some reason that these objects are not
allowed to be evaluated. But the reason is not known.
This simplification is convenient both for the user and for the implementor.
Note that some implementations such as Exper Common Lisp signal an error
when those objects that CLtL does not explicitly say are self-evaluating
are being evaluated.
<<The Rationale for this could easily be provided in the standard.
Does this need an Issue? >>
2) Arguments of function are evaluated left to right. [12.1]
<<This is clearly stated and should be even more ambiguous given a
formal semantics. I think no issue. >>
3) It should be an error if two variables specified in a single lambda
list are named by a same symbol. [15.2]
<<This was discussed in the CL mail, but I suppose it needs
New issue LAMBDA-LIST-DUPLICATES? >>
4) For mapping functions (MAPCAR, SOME, EVERY, etc.) and DOLIST,
it is an error to perform destructive operations on the mapping argument.
The result will be implementation dependent. [7.8.4]
<<New issue MAPPING-DESTRUCTIVE-INTERACTION?>>
5) Property lists are global. There is no local property list even if
the symbol is locally bound. (Common Sense?) [10.1]
<<This is just confusion; symbols are not variables, they just name them.
I think no issue.>>
*************************************************************************
The following subjects are loosely stated in CLtL, and should be clarified.
*************************************************************************
1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3]
<< I think this is a wording change rather than an Issue.>>
2) (LAMBDA (X) X) is both of the LIST type and of the FUNCTION type. [2.13]
Umemura: Cons cells must be regarded as function type objects, since
it is strange to check the syntactic validity when the type
of an object is computed.
<< Issue FUNCTION-TYPE would address this >>
3) DEFTYPE affect only the type checking mechanism and no more and less.
[4.7]
<< I'm not sure what this means. DEFTYPE also affects TYPEP, TYPECASE. >>
4) Symbols whose names begin with & are not allowed in a lambda list. [5.2.2]
<< I don't think this is true. It is a bad idea, but it isn't required.
Issue? >>
5) Same keyword parameter can appear more than once in an actual argument
list. [5.2.2]
This is necessary to overwrite passed keyword arguments.
<< New issue KEYWORD-ARGUMENT-DUPLICATES? >>
6) #C(5/3,7.0) is converted to #C(1.66666,7.0) because
real part and imaginary part must be of the same for efficient
calculation on complex numbers. [2.1.4]
<< This is clear, I thought, from CLtL >>
7) For destructive sequence functions such as DELETE, it is an error
to use the side effect of original data structure.
Implementation dependent result will be returned.
It is possible to defined DELETE as
(defun delete (&rest↓αβ∧¬επλ
!
∞∂⊂⊃∩∪∀∃⊗↔←→≠$≤ by REMF-DESTRUCTION-UNSPECIFIED >>
8) It is an error to apply non-list arguments for the list handling
functions. [15.5]
<< I think is specified. No issue? >>
9) Structures defined with the option :TYPE LIST are simple lists
and there is no way to distinguish these data from lists. [19.5]
<< I this is specified. No issue? >>
**********************************************************
The following subject have problems in CLtL specification.
**********************************************************
1) ------
Q: What happens if a function is defined in a body of a function.
For example:
(defun bar ()
(bar)
(defun bar () (something))
(bar) ) ; <-- Should BAR be affected in the execution of FOO?
A: CLtL says the DEFUN is a simple macro which changes the symbols definition.
So, BAR should be affected.
Problems: If so, the tail merging optimization is very difficult.
We cannot know how to define the effect of DEFUN in order to allow this
optimization.
Yuasa: How about defining only the compiler semantics?
For almost all Common Lisp programs run in compiled code.
<< Unless BAR is proclaimed INLINE, you have to do tail optimization
by indirect thru the function cell. This was discussed at length.
Does this need an issue? FUNCTION-TAIL-RECURSION?>>
2) -----
Q: Is it possible to redefine predefined (built-in) functions and macros
such as DEFUN, AND, OR.
A: CLtL says nothing about this thing, but almost all implementations
allow such redefinition.
Problems: We cannot image what happens.
Suggestion: Redefining a predefined symbol signals an error.
However, Redefining user function does not signals an error.
<< This is issue LISP-SYMBOL-REDEFINITION >>
3) ---
Q: Is there any way to cancel the PROCLAIM.
A: No. There should be such a function.
<< Well, PROCLAIM-LEXICAL had such, but is in trouble. >>
4) ---
Q: Is there any way to escape from Lisp context.
A: Some systems, such as Lisp machine have no concept of escaping.
This is needed for Lisp systems under stock operating systems.
It is necessary to determine the name even if the function
may be implementation dependent.
Recommendation: (QUIT) will be a proper word for this operation.
<< Seems like it goes in the environment section. >>
5) --
Q: Is it possible to UNINTERN the DEFCONSTANTed symbols.
A: CLtL says yes, but it is hard to compile such a program.
Umemura: We should define the semantics of compile-file.
Changing readbase, readmacro, packaged in a file
also introduce similar problems.
<< This seems to be mainly about UNINTERN during file compilation.
seems like this is part of the compiler specification. >>
***************************************************************
These function can be defined in CLtL itself, but should be
added to CLtL for the efficiency or user convenience.
***************************************************************
1) ---
Q: Is there any way to test whether a symbol is special or not?
A: We can define such a function in a tricky way,
But there should be this function, for compiler needs this function
and it seems that almost all implementations support such a function
internally.
<< This has been asked for before. Issue SPECIAL-VARIABLE-TEST ? >>
∂15-Dec-87 1050 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 15 Dec 87 10:50:00 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA18399; Tue, 15 Dec 87 11:45:11 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA02778; Tue, 15 Dec 87 11:45:06 MST
Date: Tue, 15 Dec 87 11:45:06 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712151845.AA02778@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST
I'm confused as to what the current status is here. Should I revise my
earlier proposals that deal primarily with syntax, or work on a new one
that tries to address the question of function declaration semantics as
well?
-Sandra
-------
∂15-Dec-87 1128 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Dec 87 11:28:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 DEC 87 11:26:03 PST
Date: 15 Dec 87 11:26 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 15
Dec 87 11:45:06 MST
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871215-112603-1532@Xerox>
I apologize for sidetracking your original proposal with the related one of
whether function argument declarations have semantics at all. It did seem to me
that deciding whether one writes
(function + (&rest number) number)
or
(function + (&rest (list number)) number)
might wait for some resolution of whether there is any conceivable utility,
other than documentation, for making either declaration, lest the issue bee
moot.
However, we probably should go forward with the discussion of the form of the
declaration independent of its semantics, and separate out, say,
FUNCTION-ARGUMENT-TYPE-SEMANTICS, from FUNCTION-TYPE-REST-LIST-ELEMENT.
If there's no objection to doing so, I'll open up another issue name, and
attempt to write up a FUNCTION-ARGUMENT-TYPE-SEMANTICS.
∂16-Dec-87 1538 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 15:38:43 PST
Received: by labrea.stanford.edu; Wed, 16 Dec 87 15:27:56 PST
Received: from gypsy-moth.lucid.com by edsel id AA09557g; Wed, 16 Dec 87 14:25:00 PST
Received: by gypsy-moth id AA01336g; Wed, 16 Dec 87 14:25:56 PST
Date: Wed, 16 Dec 87 14:25:56 PST
From: Ken Olum <edsel!kdo@labrea.stanford.edu>
Message-Id: <8712162225.AA01336@gypsy-moth.lucid.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 23 Oct 87 15:22 PDT <871023-152308-1515@Xerox>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal)
I don't think this issue has anything to do with symbols. For example,
consider the form
(setf (ldb (byte 8 0) x) (prog1 1 (setf (ldb (byte 8 8) x) 2)))
Suppose that X is 0. This form now sets X to 1. However, if X is
replaced with (CAR X), then the form will set (CAR X) to #x201. In
order to have constant behavior, GETF and LDB must ALWAYS completely
evaluate their subform, whether it is a symbol or not. If we do this
with all setf-methods then we might as well flush the idea of an
access-form since this must always be no more than a local variable
reference. Furthermore the access-form must always be defined even
if the case is just SETF, because you will always access it as EB
points out in a previous message.
Furthermore, I think this behavior is unnatural. Many applications
set up flag-words and the like, and a side-effect of computing a value
for one flag might well be the setting of another flag in the same
word. In this case the same sub-place is being used to store various
objects, and there should be as little interaction between the setting
of the different objects as possible.
Therefore, I propose that we change the definition of a subform for
this order-of-evaluation issue and keep the methods on both pages 105
and 106. See SETF-METHOD-FOR-SYMBOLS:CHANGE-MEANING-OF-SUBFORM below.
!
ISSUE: SETF-METHOD-FOR-SYMBOLS
References: CLtL pp. 105, 106, 99. Issue: PUSH-EVALUATION-ORDER.
Category: CHANGE
Edit history: Version 1 Moon 21 Sep 87
Version 2 Masinter 23-Oct-87
Version 3 Masinter 11-Nov-87
Version 4 KDO 4-Dec-87
Problem description:
The description of SETF in CLtL and various SETF methods are
inconsistent. The description on page 99 clearly requires side-effects
to be elaborated in left-to-right order; however, the combination of the
sample setf-method for LDB on p.106 and the sample setf-method for
symbols given on p. 105 results in incorrect order of evaluation.
Test Case A: Given
(LET* ((R (LIST 'A 1 'B 2 'C 3))
(S R))
(SETF (GETF R 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
If side-effects are elaborated in left-to-right order, the setq of R to
NIL should not affect the result, since it occurs after R is read and
before R is written, and therefore the value of both R and S should be
(A 1 B 6 C 3).
A typical result in an implementation that believes CLtL p.105 more than
CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3).
Test Case B: Given:
(LET((A 0))
(INCF (LDB (BYTE 2 2) A) (SETQ A 2))
A)
Does this return 8, 10, or 2? If p. 99's description of order of
evaluation is correct, this should return 8.
It was pointed out that it is possible to get the required result for
the test case by modifying the get-setf-method for GETF (and other
setf-able items) to set up the bindings when the modified form is a
symbol, as is done in Spice Lisp.
However, we believe that user programs are much more likely to have
copied the setf method for LDB given on p.106 than the setf method for
symbols schematized on p.105, and this is the simplest change to achieve
compatibility and correct behavior.
Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE
Change the example of the result of
(GET-SETF-METHOD 'FOO) from
NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO
(as currently described in CLtL) to return, for example,
(#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175
Rationale:
The general principle mentioned on p.99 should override the specific
example on p.105. The latter is probably just a mistake.
Current practice:
Symbolics and Lucid return the incorrect result mentioned in the test
case A. (Symbolics plans to fix this in the next release.) Franz and
Xerox returns something else: R = nil and S = (a 1 b 6 c 3); Xerox
returns A=10 in Test Case B. HP Common Lisp produces the recommended
value.
Spice Lisp returns the recommended value for the test case A, even
though it uses the suggested value for the setf-method for symbols,
because the get-setf-method for GETF introduces additional temporary
bindings.
Adoption Cost:
SETF is an intricate part of Common Lisp, and the fact that not all
implementations currently return the same thing indicates that some care
might be required in updating implementations. However, in some
implementations changing what get-setf-method returns when its argument
is a symbol is the only change required.
It's been pointed out that this change might cause less efficient code
to be produced in some cases, since setf methods will involve more
temporary variables, however Moon believes that the optimizations are
not difficult and probably are already done by most implementations.
Cost of non-adoption:
Users will think SETF is complicated and hard to understand, because
implementations won't conform to a simple general principle that
side-effects are elaborated in left-to-right order.
Benefits:
Improved portability of Common Lisp programs.
Conversion Cost:
This change is incompatible because it changes the result of some forms
that are not erroneous. However, it's unlikely that very many users are
intentionally depending on the current behavior. In addition, the
current behavior is not consistent across implementations, which makes
changing it less problematic.
Esthetics:
See "cost of non-adoption".
Discussion:
A specification of Common Lisp would do well to included some better
examples of precisely what is meant by the "`obvious' semantics"
mentioned on page 99.
This proposal is consistent with PUSH-EVALUATION-ORDER:ITEM in affirming
the left-right order of evaluation of subforms of generalized variable
access forms.
It was pointed out that it is possible to get the required result for
the test case by modifying the get-setf-method for GETF (and other
setf-able items) to set up the bindings when the modified form is a
symbol, as is done in Spice Lisp.
However, we believe that user programs are much more likely to have
copied the setf method for LDB given on p.106 than the setf method for
symbols schematized on p.105, and this is the simplest change to achieve
compatibility and correct behavior.
Proposal: SETF-METHOD-FOR-SYMBOLS:CHANGE-MEANING-OF-SUBFORM
Keep the old definition for symbols as examplified on p. 105 and the
definition for LDB on p. 106. Specify that "subforms of
generalized-variable references" on p. 99 does not includes subforms
which will be stored into, but only those necessary to specify the
place to store. In other words if the setf-method for a form must
recusively make use of the setf-method for a subform, that that
subform (but not any sub-subforms) is permitted to be evaluted at the
time of the store instead of in its lexical position.
Benefits:
Anyone who has copied examples from p.105 and p.106 will continue to
be able to use them.
Setf of (LDB ... X) will be consistant with (LDB ... (CAR X)) and all
other subplaces.
It is very unlikely that anyone is depending on the left-to-right
evaluation in this case, but quite possible that someone is depending
on the non-left-to-right evaluation for maintaining several bit-fields
in a symbol value.
∂17-Dec-87 1736 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:35:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306483; Thu 17-Dec-87 20:35:35 EST
Date: Thu, 17 Dec 87 20:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup issues from Japanese technical working group
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <871210-231038-2589@Xerox>
Message-ID: <19871218013528.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I have comments on excerpts from this. For most of the issues
raised, I have no comment. Feel free to forward these comments
back to our Japanese friends if desired.
1) CLtL says nothing about whether structure or array is self evaluating
form. [5.1.1]
It is suggested that not only numbers, characters, and bit-vectors,
but also structures, arrays, vectors, packages be self-evaluating forms.
Yuasa: There may possibly be some reason that these objects are not
allowed to be evaluated. But the reason is not known.
This simplification is convenient both for the user and for the implementor.
Note that some implementations such as Exper Common Lisp signal an error
when those objects that CLtL does not explicitly say are self-evaluating
are being evaluated.
<<The Rationale for this could easily be provided in the standard.
Does this need an Issue? >>
It's not true that CLtL says nothing about this; the bottom of page 54
in the English edition says evaluating any other object is an error.
I don't know what the rationale was; unless somebody knows, we can't easily
provide it in the standard!
At Symbolics we pondered this for a while and settled on the idea that
only objects of type (OR CONS SYMBOL) do anything special when evaluated,
and all other objects evaluate to themselves. We haven't had any problems
as a result of this.
CLtL says something about implementation-dependent extensions for
evaluating other types of objects, but we decided that this didn't make
sense for any of the object types defined by CLtL. An implementation
could certainly invent a new, non-COMMON object type with a new way of
evaluating it, and then that (OR CONS SYMBOL) would be extended to (OR
CONS SYMBOL other-type) in that implementation. But since a portable
program presumably wouldn't use any objects of that
implementation-dependent type, this should't interfere with portability
even if we define that all objects of types defined by CLtL, other than
CONS and SYMBOL, are self-quoting.
Evidently current practice varies between implementations. This needs an
issue if we want to change it, but since "is an error" allows complete
implementation-dependent freedom, we don't have to say anything if we
think the status quo is okay.
1) If read-base is 16, `1E0' is read as an integer and not a float. [2.1.3]
<< I think this is a wording change rather than an Issue.>>
I don't think this is a problem at all, since 22.1.2 (page 343) is very
explicit about this.
5) Same keyword parameter can appear more than once in an actual argument
list. [5.2.2]
This is necessary to overwrite passed keyword arguments.
<< New issue KEYWORD-ARGUMENT-DUPLICATES? >>
Not an issue, 5.2.2 (page 62 in the English edition) is already very
explicit about this "If more than one such argument pair matches,
it is not an error; the leftmost argument pair is used."
4) ---
Q: Is there any way to escape from Lisp context.
A: Some systems, such as Lisp machine have no concept of escaping.
This is needed for Lisp systems under stock operating systems.
It is necessary to determine the name even if the function
may be implementation dependent.
Recommendation: (QUIT) will be a proper word for this operation.
<< Seems like it goes in the environment section. >>
I remember this was discussed at length a couple years ago, and the
conclusion was that the semantics of quitting varied so much between
implementations that there was no point in trying to standardize
anything. Even without thinking about multiprocess systems, nor about
Lisp machines, you have to ask whether after quitting the Lisp vanishes
or can be restarted, whether a command string can be returned to the
operating system, whether a success/failure code is required to be
returned to the operating system, etc. Finally it is unclear how a
portable program could usefully benefit from this.
∂17-Dec-87 1740 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:40:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306486; Thu 17-Dec-87 20:39:48 EST
Date: Thu, 17 Dec 87 20:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: Dan L. Pierson <pierson@MULTIMAX.ARPA>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712072340.AA01767@multimax.ARPA>
Message-ID: <19871218013945.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL as well as
KMP's suggested improvement to the test case, which I was
going to suggest myself. The COMPILED-FUNCTION type
specifier is not well-defined and if I remember correctly
the FUNCTION-TYPE cleanup issue proposes to remove it.
∂17-Dec-87 1745 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:45:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306494; Thu 17-Dec-87 20:45:27 EST
Date: Thu, 17 Dec 87 20:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871208-160538-5539@Xerox>
Message-ID: <19871218014525.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 8 Dec 87 15:22 PST
From: Masinter.pa@Xerox.COM
I think we should take a step back and ask what the place of DISASSEMBLE, ED,
TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard. These are
things for which constructing a denotational semantics is not feasible, cann't
be easily tested with a validation suites, etc.
I think a more global change of status for these is called for; I'd propose that
the ANSI Standard should say something like:
"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."
This seems like a reasonable idea, although it's perhaps not in the domain of
the Cleanup committee.
Once we move away from conformance and standard into recommendation, we might
actually be more able to make better progress recommending, for example, that
systems call their GC function (GC) and their exit function (EXIT) etc.
I think this would be a mistake. The functions listed earlier are to be called
by users and generally are not useful to call from programs. The only reason those
functions were ever in CLtL as functions is that Common Lisp didn't want to assume
that some kind of command processor, separate from Lisp evaluation, exists since
opinions on how this should work diverge so wildly.
GC and EXIT are in a different category. GC is likely to be called by programs,
except that as we found when we discussed it a while back, it doesn't seem to be
possible to say anything at all implementation-independent about the semantics
of this, which makes it not very useful for portable programs. EXIT surely must
be for programs, rather than users, since every operating system already has a
way for users to get out; but again there is no portable semantics.
While it's useful to have some "suggested features" for users, to ease learning
how to use a new Common Lisp implementation as well as to give implementors an
idea of the minimum environment expected, it's not useful to have "suggested
features" for programs, since if they are only suggested, no portable program
can use them.
∂17-Dec-87 1757 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:57:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306500; Thu 17-Dec-87 20:57:01 EST
Date: Thu, 17 Dec 87 20:56 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
To: Dan L. Pierson <pierson@MULTIMAX.ARPA>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8712072337.AA01737@multimax.ARPA>
Message-ID: <19871218015659.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor REDUCE-ARGUMENT-EXTRACTION:KEY.
I'd like to see a version 2 of this proposal, amended according to
the comments received. The changes would all be to the form of the
proposal, not its substance, but would make it more approvable.
Proposals containing test cases that have not been tested are
a real no-no!
∂17-Dec-87 1805 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:05:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306504; Thu 17-Dec-87 21:05:03 EST
Date: Thu, 17 Dec 87 21:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12357112955.BABYL@C.CS.CMU.EDU>
Message-ID: <19871218020501.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 9 Dec 1987 10:28 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
2. Add an extended form for the LIST type specifier so that one can
indicate element type and, perhaps, length. This can be used to say
something useful about rest-args, without having to put in ugly special
syntax for this.
I very strongly prefer having the thing after the &rest in a function
type-specifier refer to each remaining argument, as Steele suggested two
years ago, rather than having it refer to the value of the &rest parameter,
as you seem to be assuming. This is partly because I very strongly prefer
having the function type-specifier be a description of arguments rather
than a description of parameters.
Thus I prefer
(function + (&rest number) number)
over
(function + (&rest (list number)) number)
I really have no opinion on the other features being discussed in this
conversation, including the very existence of the list form of the
function type-specifier. All this stuff seems both overcomplicated and
useless to me, but that's not an informed opinion.
∂17-Dec-87 1812 CL-Cleanup-mailer Cleanup issues from Japanese technical working group
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:12:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Thu 17 Dec 87 21:12:34-EST
Date: Thu, 17 Dec 1987 21:12 EST
Message-ID: <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Cleanup issues from Japanese technical working group
In-reply-to: Msg of 17 Dec 1987 20:35-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
It's not true that CLtL says nothing about this; the bottom of page 54
in the English edition says evaluating any other object is an error.
I don't know what the rationale was; unless somebody knows, we can't easily
provide it in the standard!
At Symbolics we pondered this for a while and settled on the idea that
only objects of type (OR CONS SYMBOL) do anything special when evaluated,
and all other objects evaluate to themselves. We haven't had any problems
as a result of this.
I remember some of the discussions on this issue (though I no longer
remember which side I was on -- scary!). A number of people wanted to make all
objects other than Conses and Symbols be self-evaluating; a number of
other people didn't want to close off the space of possible extensions
in this way. The latter group won.
In retrospect, it seems clear that this was a mistake -- nobody has used
the added freedom as far as I know, and the need to quote such things as
vectors has definitely led to confusion among new users and an
occasional spurious bug report. I'd support a move to change this, so
that we could all assume self-evaluating objects when we're writing
portable code. Since "it is an error" to eval objects of miscellaneous
types, implementations are legally free to adopt the self-eval
convention, but I would argue that it is a bit treacherous for their
users if they do, since the local users will be in for a nasty surprise
whenever they move to a system that doesn't use this convetion.
On the Quit issue, I think that Masinter has suggested the right way to
handle this: ed, dribble, and friends should be suggested names for
certain environment-related operations, but nothing more. The standard
would explicitly say that these environment functions may or may not
exist in any given implementation, and that what they do will vary from
one environment to another. CLtL currently says a bit too much about
some of these things, which causes people to want to say even more.
-- Scott
∂17-Dec-87 1823 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:22:55 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Thu 17 Dec 87 21:22:49-EST
Date: Thu, 17 Dec 1987 21:22 EST
Message-ID: <FAHLMAN.12359329156.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-DECLARATION issues
In-reply-to: Msg of 17 Dec 1987 21:05-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I very strongly prefer having the thing after the &rest in a function
type-specifier refer to each remaining argument, as Steele suggested two
years ago, rather than having it refer to the value of the &rest parameter,
as you seem to be assuming. This is partly because I very strongly prefer
having the function type-specifier be a description of arguments rather
than a description of parameters.
Thus I prefer
(function + (&rest number) number)
over
(function + (&rest (list number)) number)
Hmmm...I never thought about it this way. If we look at the syntax you
prefer as a special case for talking about the elements in the rest
list, then this is a hideous kludge. On the other hand, if we look at
this as a way of talking about the type of each of the rest arguments,
then it has a certain elegance. I wouldn't object, as long as it's
explained this way.
We may still want to adopt a better type specifier for LIST, but that is
a separable issue.
-- Scott
∂18-Dec-87 1439 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan)
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Dec 87 14:39:50 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa20706; 18 Dec 87 17:33 EST
Received: from tektronix.tek.com by RELAY.CS.NET id bz29779; 18 Dec 87 17:26 EST
Received: by tektronix.TEK.COM (5.51/6.24)
id AA17683; Fri, 18 Dec 87 11:41:33 PST
Received: by tekchips.TEK.COM (5.51/6.24)
id AA22225; Fri, 18 Dec 87 11:40:04 PST
Message-Id: <8712181940.AA22225@tekchips.TEK.COM>
To: Fahlman@C.CS.CMU.EDU
Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU,
willc%tekchips.tek.com@RELAY.CS.NET
Subject: whether random objects self-evaluate (was cleaup issues from Japan)
In-Reply-To: Your message of Thu, 17 Dec 1987 21:12 EST.
<FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU>
Date: 18 Dec 87 11:40:02 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Let me report on the Scheme situation and my experience. As in Common Lisp,
it is "an error" to evaluate a random object, but most implementations
extend the language by allowing at least some random objects (notably
the empty list, since only a few implementations yet distinguish the empty
list from #f) to evaluate to themselves. MacScheme allows all random objects
to evaluate to themselves, but unlike Symbolics I have found this to be
a (minor) problem, and I recommend that implementors avoid my mistake.
The problem: In writing a macro using backquote I sometimes leave out a
quote mark, insert an extra comma, or put a comma in the wrong place.
Then an expanded macro can look like
(... #<PROCEDURE> ...)
when I wanted it to look like
(... '#<PROCEDURE foo> ...)
or
(... (lambda (...) ...) ...).
I would like to get an error message from the incremental compiler, because
I never deliberately write code with unquoted procedures, but with
self-evaluating procedures no error will occur until the expression is
executed, and then the values seen in the debugger can seem very strange.
In my code, this kind of macro bug almost always shows up as a procedure
that was closed in the wrong environment, but if I'm unlucky the incorrect
procedure will pass control to an altogether unfamiliar part of the system
before trapping on some unrelated error such as taking the car of the empty
list.
As better macro facilities become more universal, this is of course
becoming less of a problem.
Peace, Will
∂18-Dec-87 1759 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 17:58:59 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 18 Dec 87 20:58:45-EST
Date: Fri, 18 Dec 1987 20:58 EST
Message-ID: <FAHLMAN.12359586922.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.com@RELAY.CS.NET
Cc: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: whether random objects self-evaluate (was cleaup issues from Japan)
Will,
It would be easy enough to say that most objects are self-evaluating,
but that function objects (strict definition) signal an error if you
evaluate them. Then again, it would be nice to avoid making odd
exceptions of this kind -- I've heard tell that some people think Common
Lisp already is something of a kludge. I wonder if the problem you cite
is as likely to occur in Common Lisp as it is in Scheme. I've never
seen this in my own coding, but that might be because I am terribly
conservative in my use of backquotery. What do others think?
-- Scott
∂21-Dec-87 1924 CL-Cleanup-mailer SETF-METHOD-FOR-SYMBOLS Issue
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 21 Dec 87 19:22:17 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA16788; Mon, 21 Dec 87 15:10:11 PST
Date: Mon, 21 Dec 87 15:10:11 PST
Message-Id: <8712212310.AA16788@decwrl.dec.com>
From: greek%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: SETF-METHOD-FOR-SYMBOLS Issue
I spent some time reading the issue entitled SETF-METHOD-FOR-SYMBOLS.
Seems to me it avoids the real question.
Consider Test Case A. Once the (GETF ...) and (PROGN ...) are
evaluated, what happens. We notice that the key B already appears in
the list, so we replace its value with 6. Then do we store the list
back in R? If so, R will be (A 1 B 6 C 3). If not, it will be NIL.
Now if the key does not appear in the list, we must cons it on the front
and then are forced to store it back in B. So perhaps for consistency
we should always store it back.
So I guess my question is: is the place in (SETF (GETF R ...) ...)
R or is it the list in R or is the pair in the list in R?
- Paul Anagnostopoulos